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Government  and  industry  have  the  need  to  assess  the  maturity  of  their  internal  software 
acquisition  processes.  The  purpose  of  assessing  the  maturity  of  organizations'  software 
acquisition  processes  is  to  identify  areas  needing  improvement.  In  order  for  organizations  to 
make  improvements,  they  must  know  the  ultimate  goal  and  what  is  required  to  achieve  that  goal. 
Additionally,  progress  toward  achieving  the  goal  must  be  measurable.  A  capability  maturity 
model  provides  the  framework  needed  to  facilitate  the  desired  improvement.  The  Software 
Acquisition  Capability  Maturity  Model  (S  A-CMM)  has  been  developed  to  provide  such  a 
framework. 

The  S  A-CMM  must  remain  viable.  After  this  model  has  been  used  by  a  variety  of  acquisition 
organizations,  it  is  anticipated  that  a  revision  will  be  published.  This  new  version  should 
incorporate  the  results  of  lessons  learned  from  the  use  of  Version  1.0,  include  changes  necessary 
to  stay  abreast  of  the  evolving  state-of-the-practice  in  software  acquisition,  and  improve  the 
understandability  and  applicability  of  the  S  A-CMM.  Therefore,  constructive  comments  resulting 
from  the  use  of  Version  1.0  of  the  SA-CMM  are  not  only  welcome  but  encouraged. 

The  Context  of  the  SA-CMM 

The  experience  of  the  Software  Engineering  Institute  in  developing  the  Capability  Maturity  Model 
for  Software  (SW-CMM)  was  directly  applicable  to  developing  the  SA-CMM.  The  SW-CMM 
describes  the  developer's  (contractor's)  role  while  the  SA-CMM  describes  the  buyer's  (acquirer's) 
role  in  the  software  acquisition  process.  In  the  SA-CMM  software  acquisition  begins  with  the 
process  of  defining  a  system  need.  Some  activities  performed  by  the  acquisition  organization  may 
pre-date  the  establishment  of  a  project  office.  The  SA-CMM  includes  certain  pre-contract  award 
activities,  such  as  preparing  the  solicitation  package,  developing  documentation  requirements,  and 
participating  in  source  selection.  During  the  engineering  phase  of  the  project,  the  two  models  are 
parallel  in  their  treatment  of  the  processes  involved.  The  SA-CMM  ends  when  the  contract  for 
software  products  and  services  is  concluded. 

Although  the  SA-CMM  is  logically  consistent  with  the  SW-CMM,  it  is  not  a  mirror  image  of  the 
SW-CMM.  The  SW-CMM  addresses  the  software  engineering  (development)  process  while  the 
SA-CMM  addresses  the  software  acquisition  process.  These  are  two  different  processes  with 
different  goals  and  different  activities.  Consequently,  the  groupings  (key  process  areas)  of  the 
SA-CMM  are  different.  That  difference  does  not  mean  the  two  models  are  incompatible.  They 
do  have  the  same  architecture,  design,  format,  and  appraisal  methodology,  as  well  as  other 
similarities.  The  two  models  can  be  used  in  parallel  on  the  same  project  since  they  address  the 
same  requirements,  proceed  on  the  same  schedule,  and  pursue  the  same  objective  -  high  quality 
deliverables.  The  two  models  are  synergistic. 
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The  SA-CMM  identifies  key  process  areas  for  four  of  its  five  levels  of  maturity.  The  key  process 
areas  state  the  goals  that  must  be  satisfied  to  accomplish  each  level  of  maturity.  In  other  words, 
progress  is  made  in  stages  or  steps.  The  levels  of  maturity  and  their  key  process  areas  thus 
provide  a  roadmap  for  achieving  higher  levels  of  maturity. 

Typically  a  portion  of  the  goals  or  activities  of  some  key  process  areas  is  satisfied/performed  at  a 
lower  level.  However,  a  key  process  area  cannot  be  achieved  until  all  of  its  goals  have  been 
satisfied.  A  maturity  level  is  achieved  by  mastering  all  of  its  key  process  areas.  Once  a  maturity 
level  is  achieved,  the  model  requires  that  the  satisfaction  of  all  lower  level  goals  is  maintained. 

•The  stages  of  the  model  are  complementary  and  flow  upward.  For  example,  at  Level  2  some  of 
the  activities  of  Contract  Tracking  and  Oversight  will  result  in  corrective  actions  (a  reactive 
approach  to  defects).  This  process  grows  and  matures,  in  Level  3  the  activities  of  Contract 
Performance  Management  are  performed  to  identify  and  prepare  for  defects  before  they  occur  (a 
proactive  approach).  The  key  process  area  Contract  Performance  Management  grows  and 
matures  to  become  Quantitative  Acquisition  Management  at  Level  4  when  the  process(es)  is 
adjusted  based  on  quantitative  data.  At  Level  5,  Continuous  Process  Improvement  uses 
quantitative  data  to  optimize  process  performance  (optimizing  approach). 

The  SA-CMM  is  designed  to  be  generic  enough  for  use  by  any  government  or  industry 
organization,  regardless  of  size,  acquiring  software.  When  applying  the  SA-CMM  to  a  particular 
organization,  translations  may  need  to  be  made  (in  addition  to  tailoring  the  model  to  fit  a  specific 
acquisition).  The  SA-CMM  addresses  an  "organization"  which  is  the  parent  of  the  "acquisition 
organization."  The  acquisition  organization  specializes  in  acquisition  and  may  be  responsible  for 
more  than  one  project.  The  project  team  is  the  entity  that  has  the  responsibility  for  executing  the 
specific  acquisition.  The  project  team  is  supported  by  "other  (affected)  groups"  (functionals, 
matrix  etc.)  in  the  conduct  of  the  acquisition.  In  the  SA-CMM,  the  terms  "group,"  "team," 
"office,"  and  similar  terms  may  indicate  situations  where  the  specific  implementation  may  vary 
from  a  single  individual  assigned  part-time,  to  several  part-time  individuals  assigned  from  other 
organizations,  to  several  individuals  dedicated  full-time.  The  structure  of  the  model  must  be 
mapped  onto  the  particular  situation  where  the  model  is  being  applied.  Also,  the  terminology  of 
the  model  has  been  made  as  generic  as  possible  and  must  be  mapped  onto  the  local  situation, 
some  examples  are  "contracting  official,"  "affected  groups,"  and  "domain." 

The  SA-CMM  should  be  interpreted  in  the  context  of  the  needs  of  the  organization;  just  because 
something  is  in  the  SA-CMM  does  not  mean  it  should  be  applied  automatically.  Effective  and 
efficient  software  acquisition  processes  are  critical  to  successful  process  improvement,  but  the 
quality  of  their  output  can  only  be  determined  in  the  context  of  the  business  needs  of  the 
particular  organization. 

Use  of  the  SA-CMM  is  not  limited  to  situations  where  software  is  being  acquired  under  formal 
contract.  It  can  be  used  by  any  organization  acquiring  software  or  software-related  services.  For 
this  usage,  the  term  "contractor"  refers  to  the  organization  performing  the  software  engineering 
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effort.  The  term  "project  team"  refers  to  the  individuals  within  the  acquiring  organization  who 
have  an  assigned  software  acquisition  responsibility,  and  the  term  "contract"  refers  to  the 
agreement  between  the  organizations. 

The  SA-CMM  applies  to  the  acquisition  of  all  types  of  embedded  and  stand-alone  software 
applications,  including  those  where  commercial-off-the-shelf  (COTS)  and  non-developmental  item 
(NDI)  software  are  being  acquired,  either  as  a  part  of  a  system  or  separately.  Naturally,  the 
model  may  have  to  be  tailored  to  fit  the  specific  circumstances. 

The  SA-CMM  is  appropriate  for  use  throughout  the  entire  software  life  cycle.  During  the  life 
cycle  of  a  system,  many  individual  acquisitions  can  occur;  an  acquisition  can  occur  in  the  system's 
operational  and  support  phase  as  well  as  for  its  initial  development.  In  cases  where  products  and 
services  for  enhancing  or  reengineering  the  software  are  being  acquired,  the  software  support 
organization  takes  on  the  role  of  the  acquirer.  Thus,  the  model  is  applicable. 

The  SA-CMM  accommodates  the  software  that  is  acquired  as  a  part  of  a  total  system  acquisition. 
It  does  not  specifically  address  the  "system  acquisition"  process;  however,  it  is  in  harmony  with 
that  process. 

Every  acquisition  project  germinates  with  a  requirement,  albeit  at  a  very  high  level.  As  the 
acquisition  begins  to  form,  more  requirements  are  identified  and  refined.  This  evolution  proceeds 
and  the  set  of  requirements  continues  to  grow.  By  the  time  the  solicitation  package  is  developed, 
a  significant  set  of  software  technical  and  non-technical  requirements  exists.  For  purposes  of  the 
SA-CMM,  these  requirements  must  be  baselined  (managed  and  controlled),  not  frozen.  As 
software  requirements  further  evolve  (e.g.,  allocation,  elaboration,  and  refinement),  they  are 
incorporated  into  the  requirements  baseline,  and  managed  and  controlled.  Management  and 
control  of  the  software  requirements  remain  the  acquirer's  responsibility  even  though  the 
contractor  may  be  involved  in  the  requirements  development  process. 

A  project  should  have  established  baselines  for  the  software's  performance  (techmcal) 
requirements,  for  the  cost  of  the  software  being  acquired,  and  for  the  schedule  of  the  acquisition 
project.  The  SA-CMM  recognizes  that,  historically,  project  managers  may  not  have  had  the 
latitude  to  make  trade-offs  in  these  parameters  to  optimize  the  project.  Consequently,  the  model 
recognizes  the  necessity  of  giving  the  project  manager  the  flexibility  to  adjust  one  of  these 
baselines  for  control  and  use  in  making  trade-offs,  thereby  enhancing  the  probability  for  a 
successful  acquisition. 

The  SA-CMM  is  based  on  the  expectation  that  a  mature  organization  and  its  projects  will  do  a 
thorough  job  of  planning  an  acquisition.  The  Software  Acquisition  Planning  key  process  area 
addresses  the  planning  process  that  must  take  place  as  an  adjunct  to  managing  the  software 
acquisition  project.  Each  of  the  remaining  key  process  areas  addresses  a  planning  process  as  one 
of  the  area's  activities.  How  to  document  this  planning  is  the  option  of  the  acquisition 
organization  and  the  project  team.  The  SA-CMM  does  identify  two  specific  plans  -  the  Project 
Management  Plan  and  the  Software  Acquisition  Risk  Management  Plan.  The  method  of 
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documenting  these  two  specific  plans  is  also  the  option  of  the  acquisition  organization  and  the 
project  team.  The  resulting  project  planning  documentation  need  not  be  any  more  extensive  than 
that  of  any  well-managed  software  acquisition  project. 

The  Architecture  of  the  SA-CMM 

The  SA-CMM  defines  five  levels  of  maturity.  Each  maturity  level  (except  Level  1)  indicates 
process  capability  and  contains  key  process  areas.  Key  process  areas  contain  goals  and  five 
common  features.  The  common  features  are  attributes  that  indicate  whether  the  implementation 
and  institutionalization  of  a  key  process  area  can  be  effective,  repeatable,  and  lasting.  The  five 
common  features  are  listed  below; 

Contniitnient  to  pctfornt.  Commitment  to  perform  describes  the  actions  that  the  organization 
must  take  to  establish  the  process  and  ensure  that  it  can  endure.  Commitment  to  perform 
typically  involves  establishing  organizational  policies  and  management  sponsorship. 

Ability  to  peiform.  Ability  to  perform  describes  the  preconditions  that  must  exist  in  the  project 
or  organization  to  implement  the  software  acquisition  process  competently.  Ability  to  perform 
t5q5ically  involves  resources,  organizational  structures,  and  training. 

Activities  performed.  Activities  performed  describes  the  roles  and  procedures  necessary  to 
implement  a  key  process  area.  Activities  performed  tjqjically  involves  establishing  plans  and 
procedures,  performing  the  work,  tracking  it,  and  taking  appropriate  management  actions. 

Measurement  and  analysis.  Measurement  and  analysis  describes  the  need  to  measure  the 
process  and  analyze  the  measurements.  Measurement  and  analysis  typically  includes  examples  of 
the  measurements  that  could  be  taken  to  determine  the  status  and  effectiveness  of  the  activities 
performed. 

Verifying  implementation.  Verifying  implementation  describes  the  steps  to  ensure  that  the 
activities  are  performed  in  compliance  with  the  process  that  has  been  established.  Verifying 
implementation  typically  encompasses  reviews  by  management. 

The  Maturity  Levels  of  the  SA-CMM 

The  acquisition  organization  management  must  increase  its  involvement,  leadership,  and  discipline 
as  it  attempts  to  achieve  each  higher  level  of  maturity.  The  following  describes  the  five  maturity 
levels  of  the  SA-CMM,  highlighting  the  primary  process  improvements  made  at  each  level. 

1)  Initial -Tht  software  acquisition  process  is  characterized  as  ad  hoc,  and  occasionally  even 
chaotic.  Few  processes  are  defined  and  success  depends  on  individual  effort.  For  an  organization 
to  mature  beyond  the  initial  level,  it  must  install  basic  management  controls  to  instill  self- 
discipline. 
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2)  Repeatable  -  Basic  software  acquisition  project  management  processes  are  established  to  plan 
all  aspects  of  the  acquisition,  manage  software  requirements,  track  project  team  and  contractor 
performance,  manage  the  project's  cost  and  schedule  baselines,  evaluate  the  products  and  services, 
and  successfially  transition  the  software  to  its  support  organization.  The  project  team  is  basically 
reacting  to  circumstances  of  the  acquisition  as  they  arise.  The  necessary  process  discipline  is  in 
place  to  repeat  earlier  successes  on  projects  in  similar  domains.  For  an  organization  to  mature 
beyond  the  level  of  self-discipline,  it  must  use  well-defined  processes  as  a  foundation  for 
improvement. 

3)  Defined-  The  acquisition  organization's  software  acquisition  process  is  documented  and 
standardized.  All  projects  use  an  approved,  tailored  version  of  the  organization's  standard 
software  acquisition  process  for  acquiring  their  software  products  and  services.  Project  and 
contract  management  activities  are  proactive,  attempting  to  anticipate  and  deal  with  acquisition 
circumstances  before  they  arise.  Risk  management  is  integrated  into  all  aspects  of  the  project,  and 
the  organization  provides  the  training  required  by  personnel  involved  in  the  acquisition.  For  an 
organization  to  mature  beyond  the  level  of  defined  processes,  it  must  base  decisions  on 
quantitative  measures  of  its  processes  and  products  so  that  objectivity  can  be  attained  and  rational 
decisions  made. 

4)  Quantitative  -  Detailed  measures  of  the  software  acquisition  processes,  products,  and  services 
are  collected.  The  software  processes,  products,  and  services  are  quantitatively  and  qualitatively 
understood  and  controlled. 

5)  Optimizing  -  Continuous  process  improvement  is  empowered  by  quantitative  feedback  fi'om 
the  process  and  from  piloting  innovative  ideas  and  technologies.  Ultimately  an  organization 
recognizes  that  continual  improvement  (and  continual  change)  is  necessary  to  survive. 

Principles  Governing  the  Interpretation  of  the  SA-CMM 

Generic  Model.  The  SA-CMM  is  a  generic  model  for  broad  usage.  In  a  specific  context, 
implementation  and  improvement  needs  may  vary. 

Or gcanzational  Improvement.  The  SA-CMM  is  a  model  for  organizational  improvement.  The 
SA-CMM  focuses  on  building  the  process  capability  of  an  organization. 

Improvement  Roadmap.  The  activities  of  the  SA-CMM  describe  the  characteristics  of  a  software 
acquisition  process  that  one  would  normally  expect  to  see  at  each  maturity  leyel.  The  SA-CMM 
does  not  prescribe  how  an  organization  is  to  improve  its  processes;  it  describes  normative 
practices  of  organizations  at  five  levels  of  maturity.  The  maturity  levels  prescribe  an  ordering  of 
how  to  prioritize  process  improvement  actions. 

Key  Process  Areas.  The  SA-CMM  describes  key  process  areas  and  activities;  it  is  not  exhaustive, 
and  other  process  areas  and  activities  may  exist. 


CMU/SEI-96-TR-020 


1-5 


Introduction 


Coniprehe?7siveness.  The  S A-CMM  does  not  address  all  the  factors  that  impact  software 
acquisition.  Examples  of  excluded  topics  are  systems  engineering,  human  resources,  and 
technology. 

Process  Management.  The  quality  of  a  software  product  or  service  is  largely  governed  by  the 
quality  of  the  software  processes  used  to  develop,  acquire,  or  maintain  it. 

Process  Improvement.  Any  process  can  be  improved;  continuous  improvement  is  necessary  to 
increase  efficiency  and  maintain  competitiveness  in  a  changing  environment. 

No  One  Right  Way.  There  is  not  "one  right  way"  to  implement  a  software  acquisition  process. 
The  SA-CMM  is  not  engraved  in  stone.  Also,  except  in  a  few  carefully  chosen  instances,  the  S  A- 
CMM  does  not  mandate  how  the  software  acquisition  process  should  be  implemented  or  who 
should  perform  an  action;  it  describes  what  characteristics  the  software  acquisition  process  should 
possess. 

Technology.  The  SA-CMM  is  technology  independent.  No  specific  tools,  methods,  or 
technologies  are  mandated  by  the  SA-CMM.  Appropriate  tools,  methods,  and  technologies 
should  be  made  available  to  support  the  process. 

Professional  Judgement.  Professional  judgement  must  be  applied  when  interpreting,  for  a 
particular  organization,  the  activities  of  the  SA-CMM.  The  SA-CMM  should  be  tailored  to  fit  the 
organization;  the  organization  should  not  be  restructured  to  reflect  the  SA-CMM. 

The  Competence  Principle.  The  competence  of  the  people  doing  the  work  is  a  major  factor  in 
project  performance  and  organizational  success.  (Competence  includes  knowledge  of  the 
application  domain,  software  acquisition  methods,  and  quantitative  methods,  and  having 
interpersonal  and  problem  solving  skills.) 
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SA-CMM  Synopsis 


Level 

Focus 

Key  Process  Areas 

5 

Optimizing 

Continuous  pro¬ 
cess  improvement 

Acquisition  Innovation  Management 

Continuous  Process  Improvement 

4 

Quantitative 

Quantitative 

management 

Quantitative  Acquisition  Management 

Quantitative  Process  Management 

3 

Deflned 

Process 

standardization 

Training  Program 

Acquisition  Risk  Management 

Contract  Performance  Management 

Project  Performance  Management 

Process  Definition  and  Maintenance 

2 

Repeatable 

Basic  project 
management 

Transition  to  Support 

Evaluation 

Contract  Tracking  and  Oversight 

Project  Management 

Requirements  Development  and  Management 
Solicitation 

Software  Acquisition  Planning 

1 

Initial 

Competent  people  and  heroics 
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Level  1  -  The  Initial  Level  _ 

At  the  Initial  Level,  the  project  team  typically  does  not  provide  a  stable  environment  for  acquiring 
software.  The  project  team  is  staffed  based  on  the  availability  of  individuals,  resulting  in  a  random 
composition  of  acquisition  skills.  Software  acquisition  does  not  receive  adequate  management 
visibility.  The  project  is  pursued  in  an  ad  hoc  manner. 

There  are  no  key  process  areas  at  Level  1 . 


Level  1 :  The  Initial  Level 


This  page  intentionally  left  blank. 


Level  2  -  The  Repeatable  Level _ 

At  the  Repeatable  Level,  the  project  team  is  knowledgeable  and  supportive  of  promulgated 
policies,  regulations,  and  standards  that  relate  to  its  project  and  makes  a  dedicated  attempt  to 
comply  with  them.  Software  acquisition  management  plans  and  procedures  are  established  by  the 
project  team.  The  planning  and  tracking  of  new  projects  are  based  on  experience  with  similar 
projects.  An  objective  in  achieving  Level  2  is  to  stabilize  software  contract  management 
processes,  allowing  project  teams  to  repeat  successful  practices  employed  on  earlier  projects. 

Level  2  project  teams  have  instituted  basic  software  acquisition  management  practices  and 
controls.  All  members  of  the  team  are  committed  to  complying  with  project  plans,  required 
policies,  regulations,  and  standards.  Project  managers  track  costs,  schedules,  requirements,  and 
performance  of  the  project.  Problems  in  meeting  commitments  are  identified  when  they  arise. 
Software  requirements  are  baselined  and  the  content  is  controlled.  Software  documentation  is 
evaluated  for  compliance  with  specified  requirements.  Project  teams  work  with  their  prime 
contractors,  and  any  subcontractors,  to  establish  a  stable,  cooperative  working  environment. 
Project  teams  track  the  performance  of  the  contractor  for  adherence  with  project  plans  and  for 
ensuring  that  contractu^  requirements  are  being  satisfied. 

The  process  capability  of  Level  2  acquisition  organizations  can  be  summarized  as  being  stable  for 
planning  and  tracking  the  software  acquisition  because  documented  procedures  provide  a  project 
environment  for  repeating  earlier  successes. 

Level  2  key  process  areas  are: 

Software  Acquisition  Planning 
Solicitation 

Requirements  Development  and  Management 
Project  Management 
Contract  Tracking  and  Oversight 
Evaluation 

Transition  to  Support 
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Software  Acquisition  Planning _ 

a  key  process  area  for  Level  2:  Repeatable _ 

The  purpose  of  Software  Acquisition  Planning  is  to  ensure  that  reasonable  planning  for  the 
software  acquisition  is  conducted  and  that  all  elements  of  the  project  are  included. 

Software  Acquisition  Planning  involves  the  preparation  for  software-related  areas  in  system  level 
planning  such  as  early  budgetary  action,  schedule  determination,  acquisition  strategy,  risk 
identification,  and  software  requirements  definition.  There  are  other  traditional  software 
acquisition  planning  activities  that  must  be  performed  in  the  context  of  the  system  as  a  whole  and 
in  coordination  with  the  project  team  (e.g.,  system  requirements  development,  hardware/software 
partitioning,  system  level  software  requirements  allocation,  and  solicitation  management). 

Software  Acquisition  Planning  also  involves  planning  all  aspects  of  the  software  acquisition 
project.  Software  acquisition  planning  documentation  provides  for  implementation  of  all  software 
acquisition-related  policies. 

Software  acquisition  planning  begins  with  the  earliest  identification  of  a  role  for  software  in  the 
system  to  be  acquired.  The  process  starts  when  reasonable  resources  are  assigned  to  form  a 
project  team  for  the  acquisition,  independent  of  whether  or  not  the  team  is  formally  constituted  as 
an  organizational  entity.  Software  acquisition  planning  provides  for  conducting  and  documenting 
software  acquisition  planning  activities  and  participation  in  system  level  planning  activities  as 
appropriate. 


GrOdlS 


Goal  1  Software  acquisition  planning  documents  are  prepared  early  in  the 

acquisition  process  and  prior  to  contractual  actions  to  acquire  software 
products  and  services. 

Goal  2  Software  acquisition  plans  encompass  the  total  software  acquisition 

effort. 

Commitment  to  perform 


Commitment  1  The  acquisition  organization  has  a  written  policy  for  planning  the 
software  acquisition. 

This  policy  typically  specifies  that; 

1 .  The  implementation  of  all  software  acquisition-related  policies  is  provided  for  in  the  plans. 
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Commitment  2 


Ability  1 


Ability  2 


Software  Acquisition  Planning 


2.  The  plans  address  all  software-related  areas  of  the  acquisition. 


Some  examples  of  software-related  areas  include: 

software  acquisition  planning, 
project  management, 
solicitation, 

requirements  development  and  management, 
reuse, 

contract  tracking  and  oversight 

evaluation,  and 

transition  to  support. _ 

3 .  A  review  process  is  established  for  resolving  issues,  facihtating  acquisition  decisions,  and 
focusing  on  critical  issues  such  as  affordability  and  risk. 

4.  Responsibility  and  accountability  are  clearly  established  for  the  project. 

5.  Software  acquisition  planning  documentation  is  prepared  prior  to  solicitation  activities. 

6.  Software  acquisition  planning  documentation  is  maintained  current. 

Responsibility  for  software  acquisition  planning  activities  is  designated. 

Ability  to  perform 


The  acquisition  organization  has  experienced  software  acquisition 
management  personnel. 


E>q)erience  means,  for  example,  having  participated  in  software  acquisition  management 
planning  on  at  least  one  project,  having  a  minimum  of  five  years  acquisition  experience, 
having  knowledge  of  the  software's  application  domain,  and  having  toowledge  of  current 
software  engineering  processes  and  technology. _ 


Adequate  resources  are  provided  for  software  acquisition  planning 
activities. 

Resources  include: 

1.  Funding. 

2.  Staff. 

3.  Equipment. 

4.  Tools. 
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Activity  1 
Activity  2 


Activity  3 


Level  2:  The  Repeatable  Level 

Activities  performed 


Software  acquisition  planning  personnel  are  involved  in  system 
acquisition  planning. 

The  software  acquisition  strategy  for  the  project  is  developed  and 
documented. 

The  strategy  typically  includes  considerations  of: 

1 .  The  objectives  of  the  acquisition. 

2.  Project  constraints,  such  as  funding  and  schedules. 

3.  Available  and  projected  technologies,  such  as  reuse,  NDI,  and  COTS. 

4.  Software  acquisition  methods. 

5.  Potential  contract  types  and  terms. 

6.  End  user  considerations. 

7.  Consistency  with  the  system  acquisition  strategy. 

8.  Risk  identification. 

The  project's  software  acquisition  pfanning  is  documented  and  the 
planning  documentation  is  maintained  over  the  life  of  the  project. 


Planning  documentation  m^  be  in  a  single  document  or  in  separate  documents  depending 
on  the  specific  needs  of  the  project. _ _ _ 


Software  acquisition  planning  documentation  typically  includes: 
1 .  The  software-related  areas  of  the  project. 


Some  examples  of  software-related  areas  include: 

software  risk  identification  and  tracking, 

project  management, 

solicitation, 

requirements  development  and  management 
reuse, 

contract  tracking  and  oversight, 
evaluation,  and 

transition  to  support. _ 


2.  All  relevant  policy  for  the  software-related  areas  of  the  acquisition. 
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Activity  4 


Activity  5 


1 


Software  Acquisition  Planning 


3 .  The  tasks  to  be  perfomed. 

4.  The  required  software  acquisition  resources. 
►  Resources  include: 

*  Funding. 

*  Staff. 


*  Equipment. 

*  Tools. 

5.  The  roles  and  responsibilities  of  the  groups  involved  in  the  project. 


Typically  roles  and  responsibilities  include: 


end  user  representation  and  involvement  in  the  software  acquisition,  interface  with  system-level 
activities,  and 

team's  relationshin  with  and  resDonsibilities  to  the  acauisition  organization. 


6.  The  project's  strategic  objectives. 

7.  A  master  schedule  of  software  acquisition  milestones. 

8.  Measurements  to  determine  the  progress  of  the  software  acquisition. 


Life  cycle  support  of  the  software  is  included  in  software  acquisition 
planning  documentation. 


Life  cycle  support  provisions  topically  include: 

1 .  Identifying  adequate  facilities  and  resources  for  the  software  support  organization. 

2.  Providing  for  transitioning  the  software  fi-om  acquisition  to  operation  and  to  the  software 
support  organization. 

3 .  Providing  for  long-term  growth  and  supportability  of  the  system. 

Life  cycle  cost  and  schedule  estimates  for  the  software  products  and 
services  being  acquired  are  prepared  and  independently  reviewed. 


In  this  instance,  "independently  reviewed"  means  a  review  by  an  individual(s)  other  than 
the  author(s)  of  the  cost  and  schedule  estimates. _ 
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Level  2:  The  Repeatable  Level 


Measurement  1 


Verification  1 


Verification  2 


Measurement  and  analysis 


Measurements  are  made  and  used  to  determine  the  status  of  the  software 
acquisition  planning  activities  and  resultant  products. 


Some  examples  of  measurements  include: 
effort  expended; 
funds  expended; 

progress  towards  completion  of  software  acquisition  planning, 
the  software  acquisition  strategy,  and  life  cycle  cost  estimates;  and 
completion  of  milestones. _ 


Verifying  implementation 


Software  acquisition  planning  activities  are  reviewed  by  acquisition 
organization  management  on  a  periodic  basis. 


The  primary  purpose  of  these  reviews  by  acquisition  organization  management  is  to 
provide  awareness  of,  and  insight  into,  software  acquisition  planning  activities  at  an 
appropriate  level  of  abstraction  and  in  a  timely  manner.  The  reviews  verify  that  acquisition 
organization  policy  is  being  implemented.  The  time  between  reviews  should  satisfy  the 
needs  of  the  organization  and  may  be  lengthy,  as  long  as  adequate  mechanisms  for 
exception  reporting  are  available.  _ i 


Software  acquisition  planning  activities  are  reviewed  by  the  project 
manager  on  both  a  periodic  and  event-driven  basis. 
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Solicitation 


Solicitation _ _ _ 

a  key  process  area  for  Level  2:  Repeatable _ 

The  purpose  of  Solicitation  is  to  prepare  a  solicitation  package  that  identifies  the  needs  of  a 
particular  acquisition  and  to  select  a  contractor  who  is  best  capable  of  satisfying  the  requirements 
of  the  contract. 


Solicitation  involves  planning  and  performing  the  activities  necessary  to  issue  the  solicitation 
package,  preparing  for  the  evaluation  of  responses,  conducting  the  evaluation,  conducting 
negotiations,  and  awarding  the  contract.  Solicitation  ends  with  contract  award. 

Goals 


Goal  1  The  selection  official  selects  a  contractor  who  is  qualified  to  satisfy  the 

contract’s  requirements  for  the  project's  software-related  products  and 
services. 

Goal  2  Solicitation  activities  are  conducted  in  a  manner  compliant  with  relevant 

laws,  regulations,  policies,  and  guidance. 

Goal  3  The  software  portion  of  the  solicitation  package  satisfies  the  needs  of  the 

acquisition. 

Commitment  to  perform 


Commitment  1  The  acquisition  organization  has  a  written  policy  for  the  conduct  of  the 
software  portion  of  the  solicitation. 

This  policy  typically  specifies  that: 

1 .  Planning  for  solicitations  is  documented. 

2.  Planning  for  proposal  evaluation  activities  is  documented. 

3 .  Solicitations  are  conducted  in  a  manner  compliant  with  applicable  laws,  regulations, 
policies,  and  guidance  for  the  solicitation. 

4  Solicitation  activities  are  tailored  based  on  the  cost  and/or  complexity  of  the  software  item  or 
service  being  acquired. 
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Level  2:  The  Repeatable  Level 


Commitment  2 
Commitment  3 

Ability  1 
Ability  2 

Ability  3 


5.  The  contract  type  (e.g.,  fixed-price,  cost-reimbursement)  is  chosen  based  on  the  perceived 
risk  of  successfolly  delivering  the  required  items  while  satisfying  the  cost  and  schedule 
requirements  of  the  contract. 

Normally,  the  less  the  risk  to  the  offeror,  the  more  rigid  the  contract  type.  For  example,  a  fixed-price 
contract  type  would  be  suitable  for  a  commodity  buy  while  a  cost-reimbursement  contract  type  is  more 
suitable  for  a  research  and  development  contract. _ _ 

6.  A  selection  official  is  designated  for  each  solicitation. 

Generally,  selection  officials  are  chosen  based  on  their  authority  to  commit  the  organization  to  a 
specified  dollar  amount  which  is  equal  to  or  greater  than  the  estimated  value  of  the  solicitation. _ 

7.  The  selection  official  for  a  solicitation  has  the  ultimate  responsibility  for  the  conduct  of  the 
solicitation  and  for  selecting  the  winning  offeror. 

Responsibility  for  the  software  portion  of  the  solicitation  is  designated. 

A  selection  ofHcial  has  been  designated  to  be  responsible  for  the  selection 
process  and  the  decision. 

Ability  to  perform 


A  group  that  is  responsible  for  coordinating  and  conducting  solicitation 
activities  exists. 

Adequate  resources  are  provided  for  solicitation  activities. 


Resources  include: 

1.  Funding. 

2.  Staff. 

3.  Equipment. 

4.  Tools. 

Individuals  performing  solicitation  activities  have  experience  or  receive 
training. 


Experience  means,  for  example,  having  participated  in  a  software  acquisition  management 
role  on  at  least  one  project,  having  knowledge  in  the  domain  of  the  application  being 
acquired,  and  having  familiarity  of  current  software  engineering  processes,  products, 
technology,  and  costing  methodologies  and  tools.  Additionally,  some  individuals  must  have 
experience  in  conducting  solicitation  activities. _ _ _ 
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Solicitation 


Ability  4 


Activity  1 


I 

I 


The  groups  supporting  the  solicitation  (e.g.,  end  user,  systems 
engineering,  software  support  organization,  and  application  domain 
experts)  receive  orientation  on  the  solicitation's  objectives  and 
procedures. 

Activities  performed 


The  project  team  performs  its  activities  in  accordance  with  its 
documented  solicitation  plans. 

The  plans  typically  cover: 

1 .  The  objectives  of  the  solicitation. 

2.  Identification  of  the  contents  of  the  solicitation  package  such  as: 

►  The  software  technical  requirements. 

Some  examples  of  software  technical  requirements  include: 

functional  requirements, 
external  interfaces, 
performance  requirements, 

architecture  constraints  (e.g.,  meeting  product  line  requirements), 
design  constraints, 

quality  attributes  (reliability,  security,  maintainability,  usability,  etc.), 
reserve  and  growth  requirements,  and 

standards. _ 


►  The  statement  of  work,  including  software-related  tasks. 

Some  e.xamples  of  software-related  tasks  include: 

engineering  tasks, 

evaluation  tasks, 

support  tasks, 

documentation  tasks,  and 

life  cycle  planning  tasks. _ 


►  The  contract  documentation  and  infomation  recording  requirements. 
Some  examples  of  contract  documentation  requirements  include: 
specifications; 

test  plans,  procedures,  reports; 
study  reports; 

configuration  management  plans,  procedures,  and  reports; 
administrative,  financial,  and  management  reports;  and 
project-specific  products  and  reports. _ 
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►  The  contract  fonn(e.g.,  completion  or  term),  contract  tvpe(e.g.,  fixed-price, 

cost-reimbursement),  incentives,  and  a  list  of  deliverable  supplies  and  services. 

►  Information  on  contract  acceptance  procedures,  specific  acceptance  criteria,  and 
payment. 

►  Additional  information  guiding  contractor  performance  during  the  contract,  including 
warranty  provisions  and  required  data  rights. 

►  Guidance  on  how  the  offerors  are  to  respond,  how  the  responses  will  be  evaluated,  and 
any  additional  administrative  requirements  such  as  socioeconomic  program  compliance. 

►  Documentation  requirements  for  the  offerors  to  submit  with  their  response. 

Some  examples  of  required  submissions  include: 

a  software  engineering  plan  describing  how  offerors  will  carry  out  the  software-related  tasks 
specified  in  the  solicitation  package; 

a  risk  management  plan  describing  how  they  will  identify  and  manage  risks  associated  with  the 
software-related  tasks  called  out  in  the  solicitation  package; 

identification  of  the  measurements  to  be  used  in  the  project  and  made  available  to  the  project  office; 
a  statement  of  the  offeror’s  planned  use  of  NDL  COTS,  and  non-deliverable  software,  including  any 
limitations  on  data  rights; 

visibilit\Tor  software  engineering  task  process  and  costs  at  a  level  approbate  for  the  contract  type 
and  commensurate  with  the  degree  of  risk  related  to  the  software  acquisition; 
the  software-related  woric  to  be  performed  by  subcontractors;  and 

providing  support  for  evaluation  and  acceptance.  _ _ _ 

3 ,  The  participants,  responsibilities,  processes,  methodologies,  techniques,  and  schedules  that 
will  be  followed  in  the  conduct  of  the  solicitation. 

In  some  solicitations  a  determination  of  the  offeror’s  ability  to  perform  the  proposed  tasks,  over  and  above 
the  evaluation  of  the  material  submitted,  is  appropriate.  The  value  of  the  procurement  the  cost  of  the 
detennination.  the  staff  resources  available  to  perform  the  determination,  and  the  development  risk  are  some 
I  of  the  items  that  should  be  taken  into  account  in  determining  the  appropriateness  of  a  determination  effort. 

4  A  process  for  managing  and  controlling  the  solicitation  documents. 

Refer  to  Activity’  3  of  the  Software  Acquisition  Planning  key  process  area. 

Activity  2  The  project  team  performs  its  activities  in  accordance  with  its 

documented  proposal  evaluation  plans. 

The  proposal  evaluation  plans  typically  contain: 

1 .  A  description  of  the  proposal  evaluation  organization  structure,  including  the  participants 
and  their  responsibilities. 

2.  Proposed  pre-evaluation  activities. 

3.  A  summary  of  the  acquisition  strategy. 

4.  A  statement  of  the  proposal  evaluation  factors  and  their  relative  importance. 

The  proposal  evaluation  factors  for  software  should  contain  factors  central  to  the  success  of  the  software 
item  or  seivice  being  acquired.  _ _ _ _ _ 


I  Level  2:  The  Repeatable  Level _ _ _ Solicitation 

I  5.  A  description  of  the  proposal  evaluation  process,  methodology,  and  techniques  to  be  used. 

I  6.  A  schedule  of  significant  proposal  evaluation  milestones. 

Activity  3  Cost  and  schedule  estimates  for  the  software  products  and  services  being 

sought  are  prepared. 


Activity  4 


Software  cost  and  schedule  estimates  are  independently  reviewed  for 
comprehensiveness  and  realism. 


Activity  5 


Measurement  1 


Verification  1 


Verification  2 


In  this  instance,  "independently  reviewed"  means  a  review  by  an  individual(s)  other  than 
the  author(s)  of  the  cost  and  schedule  estimates. _ 


The  project  team  takes  action  to  ensure  the  mutual  understanding  of 
software  requirements  and  plans  prior  to  contract  award. 

Measurement  and  analysis 


Measurements  are  made  and  used  to  determine  the  status  of  the 
solicitation  activities  and  resultant  products. 


Some  examples  of  measurements  include: 

effort  expended; 
funds  expended; 

progress  towards  completion  of  solicitation  planning,  the  statement  of 
work,  contract  specifications,  evaluation  plans,  and  cost  estimates;  and 
completion  of  milestones. _ 


/i; 


Verifying  implementation 


Solicitation  activities  are  reviewed  by  the  designated  selection  official  or 
acquisition  organization  management  on  a  periodic  basis. 

The  primary  purpose  of  these  reviews  by  the  selection  official  or  acquisition  organization 
management  is  to  provide  awareness  of,  and  insight  into,  the  solicitation  activities  at  an 
appropriate  level  of  abstraction  and  in  a  timely  manner.  The  reviews  verify  that  acquisition 
organization  policy  is  being  implemented.  The  time  between  reviews  should  satisfy  the 
needs  of  the  organization  and  may  be  lengthy,  as  long  as  adequate  mechanisms  for 
exception  reporting  are  available. _ _ 


Solicitation  activities  are  reviewed  by  the  project  manager  on  both  a 
periodic  and  event-driven  basis. 
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Requirements  Development  and  Management  Level  2;  The  Repeatable  Level 

Requirements  Development  and 
Management _ 

a  key  process  area  for  Level  2:  Repeatable _ 

The  purpose  of  Requirements  Development  and  Management  is  to  establish  a  common  and 
unambiguous  definition  of  software-related  contractual  requirements  that  is  understood  by  the 
project  team,  end  user,  and  the  contractor.  Software-related  contractual  requirements  consist  of 
technical  requirements  (system  requirements  allocated  to  software)  and  non-technical 
requirements  (contractual  agreements,  conditions,  and  terms  affecting  the  software  portion  of  the 
acquisition).  This  key  process  area  is  divided  into  two  subprocesses;  development  of  software- 
related  contractual  requirements  and  the  management  of  these  requirements  for  the  duration  of 
the  acquisition. 

Software  requirements  development  involves  those  activities  in  which  system  level  requirements 
are  decomposed  and  allocated  to  software.  To  ensure  software  is  appropriately  addressed  during 
system  requirements  definition  and  solicitation  package  preparation,  the  project  team  participates 
with  the  overall  system  acquisition  team.  This  activity  often  involves  direct  participation  from  the 
end  user  to  ensure  that  system-level  requirements  are  well  understood. 

Software  requirements  management  involves  establishing  and  maintaining  agreement  among  the 
project  team,  including  the  end  user,  and  contractor  with  respect  to  the  software-related 
contractual  requirements.  It  involves  baselining  the  software  requirements  and  controlling  all 
subsequent  requirements  changes.  The  contract  and  this  key  process  area  address  both  technical 
and  non-technical  software  requirements. 

Requirements  development  and  management  begins  with  the  translation  of  operational  or  end  user 
requirements  into  solicitation  documentation  (e.g.,  specifications)  and  ends  with  the  transfer  of 
responsibility  for  the  support  of  the  software  products. 

Software-related  contractual  requirements  define  the  scope  of  the  software  effort.  Software- 
related  contractual  requirements  are  incorporated  into  software  project  plans,  activities,  and 
products  in  an  orderly  manner.  Requirements  management  ensures  that  software  requirements  are 
unambiguous,  traceable,  verifiable,  documented,  and  controlled. 

Goals 


Goal  1  Software-related  contractual  requirements  are  developed  and  maintained 

in  conjunction  with  the  end  user  and  other  affected  groups. 
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Level  2;  The  Repeatable  Level 


Goal  2 

Goal  3 

Commitment  1 


I 


Requirements  Development  and  Management 

Software-related  contractual  requirements  are  unambiguous,  traceable, 
and  verifiable. 

The  software-related  contractual  requirements  baseline  is  established  and 
managed. 

Commitment  to  perform 


The  acquisition  organization  has  a  written  policy  for  establishing  and 
managing  the  software-related  contractual  requirements. 

1 .  This  policy  typically  specifies  that: 

►  Software-related  contractual  requirements  are  documented. 

►  Software-related  contractual  requirements  are  reviewed  by: 

*  Project  management, 

*  Other  affected  groups. 

Some  examples  of  affected  groups  include: 
end  user, 

project  system  engineering, 
project  evaluation, 
project  quality  assurance, 
software  support  organization,  and 
project  configuration  and  data  management. 

►  Changes  to  the  software-related  contractual  requirements  are  reflected  in  software 
acquisition  plans,  work  products,  services,  and  activities. 

►  A  change  control  mechanism  exists  to  manage  and  control  changes  to  the  software- 
related  contractual  requirements. 

"Managed  and  controlled"  implies  that  the  software  requirements  are  baselined,  the  version  of  the 
software  requirements  at  a  given  time  (past  or  present)  is  known  (i.e.,  version  control),  and  the 
changes  are  incorporated  in  a  controlled  manner  (i.e.,  change  control). _ 


2,  Software  requirements  include: 

►  Non-technical  requirements  (e.g.,  the  contractual  agreements,  conditions,  and  terms) 
that  affect  and  determine  the  activities  of  the  software  acquisition  project. 
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Requirements  Development  and  Management 


Level  2:  The  Repeatable  Level 


Some  examples  of  contractual  agreements,  conditions,  and  terms  include; 

products  to  be  delivered, 

data  rights  for  delivered  COTS/NDI, 

delivery  dates,  and 

milestones  with  exit  criteria. _ 


►  Technical  requirements  for  the  software. 

Some  examples  of  technical  requirements  include: 

functional  requirements, 

performance  requirements, 

quality  requirements, 

design  constraints, 

architectural  constraints, 

reuse  requirements, 

supportability  requirements,  and 

external  interface  requirements. _ 


Commitment  2  Responsibility  for  requirements  development  and  management  is 
designated. 

Ability  to  perform 


Ability  1  A  group  that  is  responsible  for  performing  requirements  development 

and  management  activities  exists. 

Ability  2  Adequate  resources  are  provided  for  requirements  development  and 

management  activities. 

Resources  include: 

1 .  Funding. 

2.  Staff. 

3.  Equipment. 

4.  Tools. 


Tools  to  support  the  activities  for  managing  software-related  contractual  requirements  may  include: 

spreadsheet  programs, 
configuration  management  tools, 
traceability  tools, 
lexical  analysis  tools, 
specification  modeling  tools, 
evaluation  management  tools,  and 

prototyping  tools. . . . . . . 
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Requirements  Development  and  Management 


Ability  3 


Activity  1 


Individuals  performing  requirements  development  and  management 
activities  have  experience  or  receive  training. 

Ejqjerience  means,  for  example,  having  participated  in  a  software  acquisition  management 
role  on  at  least  one  project  and  having  experience  in  the  domain  of  the  application  being 
acquired. _ _ _ .  _ 


Some  examples  of  training  include: 

the  methods,  standards,  and  procedures  used  by  the  project; 

the  application  domain;  and 

architectures. 


Activities  performed 


The  project  team  performs  its  activities  in  accordance  with  its 
documented  requirements  development  and  management  plans. 

The  plans  typically  cover: 

1 .  The  objectives  of  the  project  team’s  requirements  development  and  management  activities. 

2.  The  activities  to  be  performed,  including  requirements  definition. 

3.  Identification  of  the  groups,  and  intergroup  coordination,  associated  with  requirements 
development  and  management  activities. 

Some  examples  of  groups  include: 

project  sv-stem  engineering, 
project  cost  analysis, 

project  configuration  and  data  management, 

project  evaluation, 

product-line  management 

project  quality  assurance,  and 

end  user.  _ 


4.  Procedures  for  requirements  development,  including  planning,  elicitation,  analysis,  and 
verification. 

5.  Procedures  for  requirements  management,  including  baseline  establishment,  change  control, 
and  status  reporting. 

6.  Procedures  to  define  attributes  that  describe  a  "satisfactory"  requirement. 
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7.  Procedures  for  impact  analysis  of  changes  to  requirements  or  introduction  of  new 
requirements,  including  performance,  cost,  and  schedule. 


8.  Resource  requirements  and  schedules  to  perform  requirements  development  and 
management  activities. 

Refer  to  Activity  3  of  the  Software  Acquisition  Planning  key  process  area. 

Activity  2  The  project  team  develops  and  baselines  the  software-related  contractual 

requirements  and  places  them  under  change  control  early  in  the  project, 
but  not  later  than  release  of  the  solicitation  package. 

1 .  Baselined  software-related  contractual  requirements  are  documented. 

2.  Software-related  contractual  requirements  are  reviewed  for  completeness,  understandability, 
and  priority. 

3.  Acceptance  criteria  for  software-related  contractual  requirements  are  established  and 
controlled. 

Activity  3  The  project  team  appraises  system  requirements  change  requests  for  their 

impact  on  the  software  being  acquired. 

Activity  4  The  project  team  appraises  all  changes  to  the  software-related 

contractual  requirements  for  their  impact  on  performance,  architecture, 
supportability,  system  resource  utilization,  and  contract  schedule  and 
cost. 

1 .  The  impact  on  existing  commitments  is  determined  and  changes  in  commitments  are 
negotiated  as  appropriate. 

Some  examples  of  changes  include: 

changes  to  commitments  made  to  individuals  and  groups  external  to  the  acquisition  organization  and 
changes  to  commitments  within  the  acquisition  organization. _ _ _ 
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Requirements  Development  and  Management 

2.  Changes  to  software  acquisition  plans,  work  products,  services,  or  activities  resulting  fi-om 
changes  in  software-related  contractual  requirements  are: 

►  Identified. 

►  Appraised  for  potential  impact. 

►  Analyzed  for  risk. 

►  Documented. 

►  Communicated  to  the  affected  groups  and  individuals. 

►  Tracked  to  completion. 

Activity  5  Bi-directional  traceability  between  the  software-related  contractual 

requirements  and  the  contractor’s  software  work  products  and  services  is 
maintained  throughout  the  effort. 

Some  examples  of  mechanisms  providing  this  traceability  include: 

the  project  team  itself  performs  and  maintains  this  traceability  and 

the  project  team  tasks  the  contractor  (or  other)  to  perform  and  maintain  the  traceability. 


Measurement  and  analysis 


Measurement  1  Measurements  are  made  and  used  to  determine  the  status  of  the 

requirements  development  and  management  activities  and  resultant 
products. 


Some  examples  of  measurements  include: 

effort  expended; 
funds  expended; 

progress  towards  completion  of  requirements  development  and  management 
planning,  the  initial  software  requirements,  and  baselining  the  software  requirements; 

number  of  change  requests  appraised;  and 

completion  of  milestones. _ _ _ 
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Verifying  implementation 


Verification  1 


Verification  2 


Requirements  development  and  management  activities  are  reviewed  by 
acquisition  organization  management  (and  the  contractor)  on  a  periodic 
basis. 


The  primary  purpose  of  these  reviews  by  acquisition  organization  management  is  to 
provide  awareness  of,  and  insight  into,  requirements  development  and  management 
activities  at  an  appropriate  level  of  abstraction  and  in  a  timely  maimer.  The  reviews  verify 
that  acquisition  organization  policy  is  being  implemented.  The  time  between  reviews 
should  satisfy  the  needs  of  the  organization  and  may  be  lengthy,  as  long  as  adequate 
mechanisms  for  exception  reporting  are  available. _ _ 


Requirements  development  and  management  activities  are  reviewed  by 
the  project  manager  on  both  a  periodic  and  event-driven  basis. 
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Project  Management 


Project  Management _ 

a  key  process  area  for  Level  2:  Repeatable 


The  purpose  of  Project  Management  is  to  manage  the  activities  of  the  project  office  and 
supporting  contract(s)  to  ensure  a  timely,  efficient,  and  effective  software  acquisition. 

Project  Management  involves  planning,  organizing,  staffing,  directing,  and  controlling  project 
office  activities,  such  as  determining  project  tasks,  estimating  software  size  and  cost,  scheduling 
activities  and  tasks,  training,  leading  the  assigned  personnel,  and  accepting  software  products  and 
services. 

Project  management  begins  when  the  project  office  is  officially  chartered  and  terminates  when  the 
acquisition  is  completed. 

Goals 


Goal  1  Project  management  activities  provide  effective  management  control  of 

the  software  acquisition  project. 

Goal  2  The  performance,  cost,  and  schedule  objectives  of  the  software 

acquisition  project  are  defined,  measured,  and  controlled  throughout  the 
software  acquisition. 

Goal  3  Problems  discovered  during  the  software  acquisition  are  managed  and 

controlled. 

Commitment  to  perform 


Commitment  1  The  acquisition  organization  has  a  written  policy  for  execution  of  the 
software  project. 

This  policy  typically  specifies  that: 

1 .  The  software-related  requirements  are  used  as  the  basis  for  planning  the  software  acquisition 
project. 

Refer  to  Activity  1  of  the  Requirements  Development  and  Management  key  process  area. 
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Project  Management 


Commitment  2 

Ability  1 
Ability  2 


Ability  3 


Level  2:  The  Repeatable  Level 

2.  The  software  acquisition  project's  commitments  are  coordinated  among  the  affected 
managers. 

3 .  Involvement  of  other  affected  groups  in  the  software  acquisition  activities  is  negotiated  and 
documented. 

Some  examples  of  affected  groups  include: 

operational  test  group. 

software  engineering  group,  and 

end  user  representatives. _ 

4.  Acquisition  organization  management  reviews  all  software-related  project  commitments 
made  to  individuals  and  groups  external  to  the  organization. 

5.  The  project's  software  acquisition  plans  are  managed  and  controlled. 

6.  A  corrective  action  system  is  to  be  established  by  the  project  team  to  record  problems  and 
,  issues  discovered. 

Responsibility  for  project  management  is  designated. 

Ability  to  perform 


A  team  that  is  responsible  for  performing  the  project's  software 
acquisition  management  activities  exists. 

Adequate  resources  for  the  project  team  and  matrix  support  persons  are 
provided  for  the  duration  of  the  software  acquisition  project. 

1 .  The  project  office  allocates  sufficient  funds  for  internal  operations,  matrix  support, 
contractual  efforts,  and  specific  mission  areas  of  responsibility. 

2.  The  project  office  is  staffed  with  the  proper  number  and  kinds  of  people  to  address  internal 
responsibilities  and  matrix  support  needed  to  accomplish  the  project's  activities. 

3.  The  project  office  plans  for  and  provides  the  equipment  needed  to  accomplish  the  project's 
activities. 

4.  The  project  office  plans  for  and  provides  the  tools  needed  to  accomplish  the  project  s 
activities. 

When  project  trade-offs  are  necessary,  the  project  manager  is  permitted 
to  alter  either  the  performance,  cost,  or  schedule  software  acquisition 
baseline. 
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Ability  4 


Activity  1 


Project  Management 


The  project  team  and  matrix  support  individual(s)  have  experience  or 
receive  training  in  project  software  acquisition  management  activities. 


Experience  means,  for  example,  having  participated  in  a  software  acquisition  management 
role  on  at  least  one  project  and  having  experience  in  the  domain  of  the  application  being 
acquired.  Additionally,  some  individuals  should  have  general  management  skills  as  well 
as  budgeting  and  scheduling  experience. _ 


Activities  performed 


The  project  team  performs  its  activities  in  accordance  with  its 
documented  software  acquisition  management  plans. 

Prqiect  software  acquisition  management  plans  typically  contain  or  reference  documents  that 
contain: 

1 .  Project  objectives,  purpose,  scope,  and  duration. 

2.  Project  summary  and  authorization. 

3 .  Project  team  structure,  roles,  and  responsibilities. 

4.  Resource  requirements. 

5.  Acquisition  strategy. 

6.  Project  performance,  cost,  and  schedule  baselines. 

7.  Coordination  and  conununication. 

8.  Risk  identification  and  tracking. 

9.  Relationship  to  s>*stems  engineering. 

1 0.  Software  engineering  approach. 

1 1 .  Integrated  logistics  support  requirements. 

1 2.  Software  support  requirements. 

1 3.  Security  policy  and  requirements. 

1 4.  Corrective  action  reporting  procedures. 

1 5.  The  extent  of  end  user  involvement  in  the  acquisition. 

Refer  to  Activity  3  the  SoftM^^are  Acquisition  Pla?ining  key  process  area. 


CMU/SEI-96-TR-020 


L2-21 


Activity  2  The  organization  of  the  project  provides  for  the  management  of  all 

project  functions. 

Activity  3  The  software  acquisition  management  activities  of  the  project  team  are 

directed  to  accomplish  the  project’s  objectives. 

This  management  fiinction  typically  includes: 

1 .  Documenting  the  roles,  responsibilities,  and  associated  authority  of  the  project  manager  and 
team  members. 

2.  Communication  among  the  project  manager  and  the  project  team  through  regularly 
scheduled  meetings  with  agendas  and  follow-up  actions. 

3 .  Obtaining  status  of  the  project  team's  activities. 

Activity  4  The  software  acquisition  management  activities  of  the  project  team  are 

controlled. 

This  management  function  typically  includes: 

1  Providing  guidance  on  the  activities  to  be  performed  by  the  project  team. 

2  Using  project  team  input  to  adjust  its  activities. 

3  Identifying  and  documenting  non-conformance  with  written  procedures  and  taking  corrective 
action. 

*  Activity  5  The  project  team  implements  a  corrective  action  system  for  the 

identification,  recording,  tracking,  and  correction  of  problems  discovered 
during  the  software  acquisition. 

Activity  6  The  project  team  tracks  project  status,  execution,  funding,  and 

expenditures  and  takes  action. 

Some  examples  of  project  tracking  activities  include: 

accumulation  of  actual  expenditures, 
periodic  progress  measurements, 
application  of  earned  value  practices,  and 
performance  evaluations.  _ 


Level  2;  The  Repeatable  Level 


Measurement  1 


Verification  1 


Verification  2 


Project  Management 

Measurement  and  analysis 


Measurements  are  made  and  used  to  determine  the  status  of  the  project 
management  activities  and  resultant  products. 

Some  examples  of  measurements  include: 

effort  expended, 
funds  expended, 

progress  towards  completion  of  project  management 
planning  and  the  organizational  strategy,  and 

completion  of  milestones. _ 


Verifying  implementation 


Project  management  activities  are  reviewed  by  acquisition  organization 
management  on  a  periodic  basis. 


The  primary  purpose  of  these  reviews  by  acquisition  organization  management  is  to 
provide  awareness  of,  and  insight  into,  project  management  activities  at  an  appropriate 
level  of  abstraction  and  in  a  timely  manner.  The  reviews  verify  that  acquisition 
organization  policy  is  being  implemented.  The  time  between  reviews  should  satisfy  the 
needs  of  the  organization  and  may  be  lengthy,  as  long  as  adequate  mechanisms  for 
exception  reporting  are  available.  _ 


Project  management  activities  are  reviewed  by  the  project  manager  on 
both  a  periodic  and  event-driven  basis. 
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Contract  Tracking  and  Oversight 


Level  2:  The  Repeatable  Level 

Contract  Tracking  and  Oversight _ 

a  key  process  area  for  Level  2:  Repeatable _ 


The  purpose  of  Contract  Tracking  and  Oversight  is  to  ensure  that  the  softAvare  activities  under 
contract  are  being  performed  in  accordance  with  contractual  requirements,  and  that  evolving 
products  and  services  will  satisfy  contractual  requirements. 

Contract  Tracking  and  Oversight  involves  providing  ongoing  inputs  and  guidance  to  the 
contractor's  effort  and  identifies  risks  and  problems  in  the  effort. 

Contract  tracking  and  oversight  begins  with  the  award  of  the  contract  and  ends  at  the  conclusion 
of  the  contract's  period  of  performance. 

The  contract  provides  the  binding  agreement  for  establishing  the  requirements  for  the  software 
products  and  services  to  be  acquired.  It  establishes  the  mechanism  to  allow  the  project  team  to 
oversee  the  contractor's  software  activities  and  evolving  products  and  to  evaluate  any  software 
products  and  services  being  acquired.  It  also  provides  the  vehicle  for  mutual  understanding 
between  the  project  team  and  the  contractor  of  the  software  requirements  of  the  contract. 

Goals 


Goal  1  The  acquired  software  products  and  services  satisfy  contractual 

requirements. 

Goal  2  The  contractor’s  software  engineering  effort  complies  with  contract 

requirements. 

Goal  3  The  project  team  and  contractor  maintain  ongoing  communication  and 

commitments  are  agreed  to  by  both  parties. 

Goal  4  The  contract,  and  any  changes,  adhere  to  relevant  laws,  policies, 

regulations,  and  other  planned  guidance  and  is  consistent  with  project 
software  acquisition  requirements. 
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Contract  Tracking  and  Oversight 


Commitment  to  perform 

Commitment  1  The  acquisition  organization  has  a  written  policy  for  the  contract 
tracking  and  oversight  of  the  contracted  software  effort. 

This  policy  typically  specifies  that: 

1 .  Planning  for  contract  tracking  and  oversight  is  documented. 

2.  Contract  tracking  and  oversight  plans  are  managed  and  controlled. 

3.  Applicable  tools  and  methodologies  are  to  be  used  to  track  the  contracted  effort. 

4.  The  integrity  of  the  contract  is  to  be  maintained  throughout  the  contract  performance  period. 

5.  Software  efforts  are  to  be  addressed  at  reviews  of  contractor  performance. 

Commitment  2  Responsibility  for  contract  tracking  and  oversight  activities  is  designated. 

Commitment  3  The  project  team  is  supported  by  contracting  specialists  in  the  execution 
of  the  contract. 

Ability  to  perform 

A  group  that  is  responsible  for  managing  contract  tracking  and  oversight 
activities  exists. 

Adequate  resources  are  provided  for  contract  tracking  and  oversight 
activities. 

Resoxirces  include: 

1.  Funding. 

2.  Staff. 

3.  Equipment. 

4.  Tools. 

Individuals  performing  contract  tracking  and  oversight  activities  have 
experience  or  receive  training. 


Ability  1 
Ability  2 


Ability  3 
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Contract  Tracking  and  Oversight 


Activity  1 


Activity  2 


Level  2:  The  Repeatable  Level 


Experience  means,  for  example,  having  participated  on  at  least  one  software  project  in 
areas  of  tracking  software  development  imder  contract,  providing  technical  guidance  to 
contractors,  and  correctly  applying  contractual  and  legal  pohcies  and  regulations  for  that 
effort.  _ ____J 


Activities  performed 


The  project  team  performs  its  activities  in  accordance  with  its 
documented  contract  tracking  and  oversight  plans. 

The  plans  typically  cover: 

1 .  Guidelines  and  criteria  used  in  defining  the  project  team's  contract  tracking  and  oversight 
activities. 

2.  Activities  to  be  performed  and  the  schedule  to  perform  these  activities. 

3.  Identification  of  groups,  assigned  responsibihties,  and  intergroup  coordination. 

4.  Extent  of  end  user  involvement. 

5.  Techniques,  tools,  and  methodologies  to  be  employed  for  review  and  tracking  of  contractor 
performance  and  compliance  of  the  evolving  software  products  and  services. 

6.  Resources  required  to  accomplish  contract  tracking  and  oversight  activities. 

7.  Procedures  to  be  followed  to  track  and  identify  issues  to  closure. 

Refer  to  ActiviW  3  of  the  Software  Acquisition  Planning  key  process  area. 

The  project  team  reviews  required  contractor  software  planning 
documents  which,  when  satisfactory,  are  used  to  oversee  the  contractor’s 
software  engineering  effort. 


Changes  to  these  plans  are  to  be  coordinated  with  the  project  team  before  being 
implemented  by  the  contractor. _ _ 


Some  examples  of  required  contractor  planning  documents  include: 
project  management  plan, 
software  risk  management  plan, 
software  engineering  plan, 
configuration  management  plan,  and 

subcontractor  management  plan. _ 
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Contract  Tracking  and  Oversight 


Activity  3 


Activity  4 


Activity  5 


The  project  team  conducts  periodic  reviews  and  interchanges  with  the 
contractor. 

These  reviews  may  include  end  user  input  as  needed.  | 


These  reviews  typically  attempt  to  ensure: 

1 .  Continuing  communications  and  mutual  understanding  of  the  contractual  software 
requirements. 

2.  The  contractor  is  implementing  activities  according  to  approved  plans. 

3 .  Open  issues  with  the  contractor  are  resolved. 

4.  The  contractor's  activities  and  results  are  addressed. 

5.  The  contractor's  evaluations  of  the  software  products  and  services  comply  with  approved 
evaluation  plans  and  procedures. 

6.  The  contractor's  corrective  action  system,  including  defect  reporting,  defect  correction,  re¬ 
testing,  and  rework,  is  being  implemented  according  to  approved  plans  and  procedures. 

7.  The  software  requirements  being  analyzed  and  documented  by  the  contractor  are 
unambiguous,  traceable,  testable,  documented,  and  controlled. 

8.  The  actual  progress  and  cost  of  the  contractor's  software  engineering  process  is  compared  to 
planned  schedules  and  budgets. 

Some  examples  of  contractor  progress  tracking  include: 

contract  woric  packages, 
periodic  progress  measurements, 
earned  value  practices,  and 

performance  evaluations. _ 

9.  Evolving  software  products  and  services  will  satisfy  software-related  contractual 
requirements,  including  functional,  performance,  operational,  supportability,  and  other 
quality  requirements. 

The  project  team  reviews  and  tracks  the  development  of  the  software 
engineering  environment  required  to  provide  life  cycle  support  for  the 
acquired  software. 

Any  problems  or  issues  found  by  the  project  team  during  contract 
tracking  and  oversight  are  recorded  in  the  appropriate  corrective  action 
system  and  tracked  to  closure. 


The  appropriate  corrective  action  system  can  be  either  the  project  team's  or  the  contractor's. 
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Contract  Tracking  and  Oversight 


Activity  6 


Measurement  1 


Verification  1 


Level  2:  The  Repeatable  Level 

The  project  team  maintains  the  integrity  of  the  contract  throughout  the 
contract  performance  period. 

Contract  integrity  is  the  adherence  and  compliance  to  relevant  laws,  policies,  regulations, 
and  other  planned  guidance. _ _ _ _ 


This  activity  typically  includes; 

1 .  Changing  the  contract  terms  and  conditions  as  appropriate. 

2.  Insuring  that  changes  to  the  software-related  contractual  requirements  are  coordinated  with 
all  affected  groups  and  individuals,  such  as  the  contracting  official,  contractor,  and  end  user. 

Measurement  and  analysis 


Measurements  are  made  and  used  to  determine  the  status  of  the  contract 
tracking  and  oversight  activities  and  resultant  products. 

Some  examples  of  measurements  include: 

effort  expended 
funds  expended, 

progress  towards  completion  of  contract  tracking  and  oversight  planning  and 
baselining  contractor  software  planning  documents, 

number  of  items  closed  in  the  corrective  action  system  used  by  the  project  team,  and 
completion  of  milestones.  _ 


Verifying  implementation 


Contract  tracking  and  oversight  activities  are  reviewed  by  acquisition 
organization  management  on  a  periodic  basis. 


The  primary  purpose  of  these  reviews  by  acquisition  organization  management  is  to 
provide  awareness  of,  and  insight  into,  contract  tracking  and  oversight  activities  at  an 
appropriate  level  of  abstraction  and  in  a  timely  manner.  The  reviews  verify  that  acquisition 
organization  policy  is  being  implemented.  The  time  between  reviews  should  satisfy  the 
needs  of  the  organization  and  may  be  lengthy,  as  long  as  adequate  mechanisms  for 
exception  reporting  are  available. _ _ _ 


Verification  2  Contract  tracking  and  oversight  activities  are  reviewed  by  the  project 
manager  on  both  a  periodic  and  event-driven  basis. 
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Level  2:  The  Repeatable  Level  Evaluation 

Evaluation _ 

a  key  process  area  for  Level  2:  Repeatable _ 

The  purpose  of  Evaluation  is  to  determine  that  the  acquired  software  products  and  services  satisfy 
contract  requirements  prior  to  acceptance  and  transition  to  support. 

Evaluation  involves  the  development  of  technical  and  non-techmcal  requirements  for  the 
evaluation  approach,  including  acceptance  criteria,  which  are  incorporated  into  both  the 
solicitation  package  and  the  contract.  Evaluations  are  conducted  during  contract  performance 
and  results  are  analyzed  to  determine  acceptability  of  the  software  products  and  services. 
Evaluation  activities  are  designed  to  reduce  interference  with  contractor-performed  evaluations 
and  to  reduce  duplication  of  evaluation  efforts.  Evaluation  builds  on  the  activities  that  establish 
and  verify  the  contractual  requirements.  Evaluation  interacts  with  the  Contract  Tracking  and 
Oversight  key  process  area. 

Evaluation  begins  with  development  of  the  system  requirements  and  ends  when  the  software 
acquisition  is  completed. 


Goals 


Goal  1  Evaluations  provide  an  objective  basis  to  support  the  decision  for 

acceptance  of  the  software  products  and  services. 

Goal  2  Evaluations  are  planned  to  provide  an  integrated  approach  which 

satisfies  all  evaluation  requirements  and  maximizes  efficiency  of  the 
activities. 

Commitment  to  perform 


Commitment  1  The  acquisition  organization  has  a  written  policy  for  managing  the 
evaluation  of  the  acquired  software  products  and  services. 

This  policy  typically  specifies  that; 

1 .  Evaluations  are  intended  to  reduce  acquisition  risk  and  to  estimate  operational  effectiveness , 
and  suitability  of  the  software  products  and  services  to  support  the  satisfaction  of  end  user 
needs. 
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Commitment  2 


Ability  1 


2.  The  project  includes  plans  for  the  evaluation  of  the  acquired  software  products  and  services 
which  specify'  critical  issues,  evaluation  objectives,  and  evaluation  criteria. 

3.  The  project's  evaluation  activities  begin  with  the  development  of  the  software-related 
contractual  requirements. 

Refer  to  Activity  2  of  the  Requirements  Development  and  Management  key  process  area. 

4.  The  project  defines  the  evaluation  requirements  for  the  software  acquisition. 


Some  examples  of  evaluation  requirements  include: 

documented  evaluation  approach  involving  the  project  team,  the  contractor,  and  other  affected  groups; 
contractor  evaluation  activities  or  tasks  required; 
contract  deliverables  such  as  test  plans  and  reports;  and 

integrated  evaluation  schedule. _ _  .  . 


5.  Results  of  the  evaluations  are  used  as  a  basis  for  acceptance  of  the  software. 

6.  Software  products  and  services  must  pass  a  successful  evaluation  of  contract  requirements 
before  acceptance. 

7.  The  project’s  software  evaluation  planning  is  updated  to  reflect  changes  to  the  software 
requirements. 

Responsibility  for  evaluation  activities  is  clearly  designated. 

Ability  to  perform 


A  group  that  is  responsible  for  planning,  managing,  and  performing 
evaluation  activities  for  the  project  exists. 

The  evaluation  group  may  include: 

1 .  Independent  evaluators. 

2.  End  users. 

3 .  Software  support  organization. 

4.  System  and  software  engineers. 

5.  Members  of  the  sofh^'are  requirements  development  and  management  group. 

Refer  to  the  Requirements  Development  Management  key  process  area. 
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Level  2:  The  Repeatable  Level 


Evaluation 


Ability  2 


Ability  3 


Ability  4 


Activity  1 


Adequate  resources  are  provided  for  evaluation  activities. 

Resources  include: 

1 .  Funding. 

2.  Staff. 

3.  Equipnent. 

4.  Tools. 


Some  examples  of  tools  to  support  software  evaluation  activities  include: 

data  collection  tools, 
static  code  analyzers, 
quantitative  analysis  software  packages, 
problem  tracking  software  packages, 
configuration  management  tools,  and 

traceability  tools.  _ 


Individuals  performing  evaluation  activities  have  experience  or  receive 
training. 


Experience  means,  for  example,  having  developed  testing  methods  for  the  evaluation  of 
software  products  and  services,  having  applied  basic  analysis  techniques,  and  having 
e\  aluated  product  quality  data  on  at  least  one  project. _ 


Members  of  the  project  team  and  groups  supporting  the  software 
acquisition  receive  orientation  on  the  objectives  of  the  evaluation 
approach. 

Activities  performed 


The  project  team  performs  its  activities  in  accordance  with  its 
documented  evaluation  plans. 

The  plans  typically  cover: 

1 .  A  summary  of  the  operational  need  and  key  operational  effectiveness  or  suitability  issues  that 
must  be  addressed  by  evaluation. 

2.  A  brief  description  of  the  s>'stem  and  key  areas  of  technical  or  engineering  risk  that  must  be 
addressed  by  evaluation. 
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3.  A  brief  description  of  the  integrated  evaluation  approach,  including  evaluation  objectives, 

the  evaluation  activities  to  be  performed,  and  the  integrated  schedule  for  these  activities. 


Activity  2 


Activity  3 


4.  The  groups  responsible  for  conducting  evaluation  activities. 

5 .  A  summary  of  the  resources  required  to  perform  the  evaluations. 

6.  The  actions  to  be  taken  when  software  product  or  service  quality  is  determined  or  projected 
to  fall  short  of  established  requirements. 

Refer  to  Activity  3  of  the  Software  Acquisition  Planning  key  process  area. 

The  project's  evaluation  requirements  are  developed  in  conjunction  with 
the  development  of  the  system  or  software  technical  requirements. 

1 .  Development  of  evaluation  requirements  involves  groups  participating  in  evaluation 
activities,  including  the  end  users. 

2. *  Development  of  evaluation  requirements  may  involve: 

►  Identifying  the  system  or  software  requirements  to  be  evaluated. 

►  Identifying  architectural  compliance  issues  to  be  evaluated. 

►  Establishing  objective  evaluation  and  acceptance  criteria. 

►  Developing  test  cases. 

►  Designing  detailed  activities  to  perform  the  evaluations. 

►  Identifying  methods  to  evaluate  the  quality  of  the  acquired  software  products  and 
services. 

Some  examples  of  methods  to  evaluate  software  include: 

using  software  engineering  methods, 
peer  reviews, 
conducting  tests. 

performing  analyses  or  inspections,  and 
applying  measurements. _ 

►  Identifying  requisite  resources  and  ensuring  that  these  resources  will  be  in  place. 

►  Developing  a  detailed  schedule  of  activities. 

►  Developing  test  environments. 

►  Ensuring  traceability  of  evaluation  requirements  to  system  requirements. 

The  evaluation  requirements  are  incorporated  into  the  solicitation 
package  and  resulting  contract. 
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Evaluation 


Activity  4 


Activity  5 


Activity  6 


Measurement  1 


The  contract  provisions  typically  include: 

1 .  Requirements  for  the  contractor  to  document  a  plan  for  an  evaluation  of  the  software 
products  and  services  prior  to  delivery. 

2.  Measurements  that  provide  the  project  team  visibility  into  the  contractor’s  evaluation 
program  and  results. 

3 .  Mechanisms  and  deliverables  that  provide  the  project  team  sufficient  data  to  allow 
evaluation  and  analyses  of  acquired  software  products  and  services. 

4.  Requirements  for  the  contractor  to  establish  a  corrective  action  system  which  includes  a 
change  control  process  for  rework  and  reevaluation. 

5 .  Requirements  to  ensure  the  contractor  supports  each  of  the  project's  evaluation  activities. 

The  project  team  assesses  contractor’s  performance  for  compliance  with 

evaluation  requirements. 

Refer  to  Activity  3  of  the  Contract  Tracking  and  Oversight  key  process  area. 

Planned  evaluations  are  performed  on  the  acquired  software  products 

and  services  prior  to  acceptance  for  operational  use. 


As  part  of  the  planned  integrated  approach,  complementary  evaluations  may  be  performed 
independently  by  the  project  team  (with  support  of  the  contractor)  to  further  reduce  the  risk 
that  the  acquired  software  products  and  services  will  fail  to  satisfy  contractual 
requirements. _ 


Any  problems  or  issues  such  as  areas  of  non-compliance  found  by  evaluation  activities  are 
recorded  in  the  appropriate  corrective  action  system.  _ 


Results  of  the  evaluations  are  analyzed  and  compared  to  the  contract’s 
requirements  to  establish  an  objective  basis  to  support  the  decision  to 
accept  the  products  and  services  or  to  take  further  action. 

Measurement  and  analysis 


Measurements  are  made  and  used  to  determine  the  status  of  the 
evaluation  activities  and  resultant  products. 
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Verification  1 


Verification  2 


Some  examples  of  measurements  include: 

elBFort  expended, 
funds  expended, 

progress  towards  completion  of  evaluation 
planning  and  of  evaluation  requirements,  and 

completion  of  milestones. _ _ 


Verifying  implementation 


Evaluation  activities  are  reviewed  by  acquisition  organization 
management  on  a  periodic  basis. 


The  primary  purpose  of  these  reviews  by  acquisition  organization  management  is  to 
provide  awareness  of,  and  insight  into,  evaluation  activities  at  an  appropriate  level  of 
abstraction  and  in  a  timely  manner.  The  reviews  verify  that  acquisition  organization  policy 
is  being  implemented.  The  time  between  reviews  should  satisfy  the  needs  of  the 
organization  and  mw  be  lengthy,  as  long  as  adequate  mechanisms  for  exception  reporting 
are  available.  _ _ _ 


Evaluation  activities  are  reviewed  by  the  project  manager  on  both  a 
periodic  and  event-driven  basis. 
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Transition  to  Support 


Transition  to  Support _ 

a  key  process  area  for  Level  2:  Repeatable _ _ 

The  purpose  of  Transition  to  Support  is  to  provide  for  the  transition  of  the  software  products 
being  acquired  to  the  eventual  software  support  organization.  The  necessary  resources  are 
identified,  budgeted  for,  and  are  available  when  needed.  The  designated  software  support 
organization  is  fully  prepared  to  accept  responsibility  for  the  software  products  in  time  to  ensure 
uninterrupted  support. 

Transition  to  Support  involves  developing  and  implementing  the  plans  for  transitioning  the 
acquired  software  products.  It  also  involves  ensuring  that  the  contractor  and  the  software 
support  organization  are  informed  on  the  contents  of  the  software  engineering  and  support 
environments.  The  project  team  provides  for  an  orderly,  smooth  transition  of  the  software 
products  from  the  contractor  to  the  software  support  organization. 

Transition  to  support  begins  with  the  earliest  definition  of  software  requirements  and  ends  when 
the  responsibility  for  the  software  products  is  turned  over  to  the  software  support  orgamzation. 

Goals 


Goal  1  The  software  support  organization  has  the  capacity  to  provide  the 

required  support  upon  assumption  of  responsibility  for  the  software 
products. 

Goal  2  There  is  no  loss  in  continuity  of  support  to  the  software  products  during 

transition  from  the  contractor  to  the  software  support  organization. 

Goal  3  Configuration  management  is  maintained  throughout  the  transition. 

Commitment  to  perform 


Commitment  1  The  acquisition  organization  has  a  written  policy  for  the  transitioning  of 
software  products  to  the  software  support  organization. 

This  policy  tj’pically  specifies  that: 

1 .  The  sofhvare  support  organization  is  identified  prior  to  developing  the  solicitation  package. 


CMU/SEI-96-TR-020 


L2-35 


Transition  to  Support 


Level  2:  The  Repeatable  Level 


Commitment  2 

Commitment  3 

Ability  1 
Ability  2 

Ability  3 

Ability  4 


2.  Resources  for  software  support  are  included  in  the  appropriate  budget(s). 

3.  The  designated  software  support  organization  is  involved,  as  appropriate,  throughout  the 
acquisition. 

The  acquisition  organization  ensures  that  the  software  support 
organization  is  involved  in  planning  for  transition  to  support. 

Responsibility  for  transition  to  support  activities  is  designated. 

Ability  to  perform 


A  group  that  is  responsible  for  coordinating  transition  to  support 
activities  exists. 

Adequate  resources  are  provided  for  transition  to  support  activities. 

Resources  include: 

1.  Funding. 

2.  Staff. 

3.  Equipment. 

4.  Tools. 

The  organization  responsible  for  providing  support  of  the  software 
products  is  identified  no  later  than  initiation  of  the  solicitation  package's 
development. 

The  software  support  organization,  prior  to  transition,  has  a  complete 
inventory  of  all  software  and  related  items  that  are  to  be  transitioned. 


Some  examples  of  related  items  include: 

software  descriptive  documentation, 
necessary  support  software, 
pertinent  data  from  the  corrective  action  and 
configuration  management  systems,  and 

maintenance  documentation. 
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Level  2:  The  Repeatable  Level 


Ability  5 


Ability  6 


Activity  1 


Activity  2 


Transition  to  Support 

Individuals  performing  transition  to  support  activities  have  experience  or 
receive  training. 


Experience  means,  fijr  example,  having  participated  in  a  software  acquisition  management 
role  on  at  least  one  project  and  having  participated  in  supporting  software  for  at  least  two 
years. _ _ _ 


The  members  of  organizations  interfacing  with  the  transition  to  support 
activities  receive  orientation  on  the  salient  aspects  of  transition  to  support 
activities. 

Activities  performed 


The  project  team  performs  its  activities  in  accordance  with  its 
documented  transition  to  support  plans. 

The  plans  typically  cover: 

1 .  The  objectives  and  scope  of  the  transition  to  support  activities. 

2.  Identification  and  involvement  of  the  software  support  organization. 

3 .  Support  resource  requirements. 

4.  A  definition  of  transition  activities. 

5.  A  schedule  of  transition  activities. 

6.  Allocation  of  transition  responsibilities. 

7.  Warranty  and  data  rights  provisions. 

Refer  to  Activity  3  of  the  Software  Acquisition  Planning  key  process  area. 

Responsibility  for  the  software  products  is  transferred  only  after  the 
software  support  organization  demonstrates  its  capability  to  modify  and 
support  the  software  products. 

This  capability  tj’pically  includes  the  availability  of: 

1 .  Hardware,  software,  physical,  fiscal,  and  personnel  resources. 

2.  Plans,  processes,  procedures,  and  documentation. 
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Transition  to  Support 


Activity  3 


Measurement  1 


Verification  1 


Verification  2 


Level  2:  The  Repeatable  Level 

3.  An  established  configuration  management  system  capable  of  supporting  the  software. 

4.  Appropriate  training  of  all  personnel  involved. 

5.  Software  replication,  test,  and  distribution  capabilities. 

The  project  team  oversees  the  configuration  control  of  the  software 
products  throughout  the  transition. 

Measurement  and  analysis 


Measurements  are  made  and  used  to  determine  the  status  of  the 
transition  to  support  activities  and  resultant  products. 

Some  examples  of  measurements  include: 

effort  expended, 
funds  expended, 

progress  towards  completion  of  transition  to 
support  planning,  and 

completion  of  milestones. _ 


Verifying  implementation 


Transition  to  support  activities  are  reviewed  by  acquisition  and  software 
support  organizations*  managements  on  a  periodic  basis. 


The  primary  purpose  of  these  reviews  by  acquisition  and  software  support  organizations' 
managements  is  to  provide  awareness  of,  and  insight  into,  transition  to  support  activities 
at  an  appropriate  level  of  abstraction  and  in  a  timely  manner.  The  reviews  verify  that 
acquisition  organization  policy  is  being  implemented.  The  time  between  reviews  should 
satisl^-  the  needs  of  the  organization  and  may  be  lengthy,  as  long  as  adequate  mechanisms 
for  exception  reporting  are  available. _ _ 


Transition  to  support  activities  are  reviewed  by  the  project  manager  on 
both  a  periodic  and  event-driven  basis. 
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Level  3  -  The  Defined  Level 


At  the  Defined  Level,  the  acquisition  organization's  standard  software  acquisition  process  is 
established,  including  the  processes  for  both  software  contract  management  and  project 
management,  and  its  use  is  integrated  into  each  project.  The  acquisition  organization  exploits 
effective  software  acquisition  techniques  when  standardizing  software  acquisition  processes. 

There  is  a  permanent  focus  on  the  process;  the  acquisition  organization's  software  acquisition 
process  group  facilitates  process  definition  and  maintenance  efforts.  Processes  established  at  the 
Defined  Level  are  tailored  as  appropriate  to  perform  more  effectively  within  the  project.  An 
organization-wide  training  program  is  implemented  to  ensure  that  all  practitioners  and  managers 
have  the  knowledge  and  skills  required  to  carry  out  their  tasks. 

Projects  use  the  acquisition  organization's  standard  software  acquisition  process  as  a  basis  for 
creating  their  own  defined  software  acquisition  process  that  encompasses  the  unique 
characteristics  of  the  project.  Because  the  acquisition  organization's  standard  software  acquisition 
process  is  well  defined  and  understood,  management  has  good  visibility  into  techmcal  progress  of 
the  project.  Management  and  engineering  activities  are  coherently  integrated  on  each  project. 
When  attempting  to  comply  with  required  policy,  the  project  team  is  capable  of  balancing  the 
intent  of  the  policy  with  a  conflicting  project  need.  The  project  team  ensures  compliance  with 
plans  and  contract  requirements  and  works  with  the  contractor  to  resolve  compliance  difficulties 
when  they  arise.  Risks  are  identified  and  managed  throughout  the  acquisition. 

The  process  capability  of  Level  3  acquisition  organizations  can  be  summarized  as  being  controlled 
since  performance,  cost,  schedule,  and  requirements  are  under  control  and  software  quality  is 
tracked.  This  capability  is  based  on  a  common  understanding  of  processes,  roles,  and 
responsibilities  in  a  defined  acquisition  process. 

Level  3  key  process  areas  are: 

Process  Definition  and  Maintenance 
Project  Performance  Management 
Contract  Performance  Management 
Acquisition  Risk  Management 
Training  Program 
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Process  Definition  and  Maintenance 


Levels:  The  Defined  Level 


Process  Definition  and  Maintenance _ 

a  key  process  area  for  Level  3:  Defined _ 

The  purpose  of  Process  Definition  and  Maintenance  is  to  establish  the  acquisition  organization's 
standard  software  acquisition  process  and  an  organizational  responsibility  for  stabilizing  and 
maintaining  the  standard  software  acquisition  process. 

Process  Definition  and  Maintenance  involves  understanding  the  organization's  and  projects' 
software  acquisition  processes,  collecting  a  set  of  software  acquisition  process  assets,  and 
coordinating  eSoits  to  appraise  and  improve  software  acquisition  processes. 

The  acquisition  organization  provides  the  long-term  commitments  and  resources  to  establish  and 
maintain  a  software  acquisition  process  group.  This  group  is  responsible  for  the  definition, 
maintenance,  and  improvement  of  the  acquisition  organization's  standard  software  acquisition 
process  and  other  process  assets,  including  guidelines  for  all  projects  to  tailor  the  standard 
software  acquisition  process  to  their  specific  situations.  It  coordinates  process  activities  with  the 
software  projects  and  related  elements  of  the  organization. 

Goals 


Goal  1  A  standard  software  acquisition  process  for  the  acquisition  organization 

is  defined,  managed,  and  controlled. 

Goal  2  Process  definition  and  maintenance  activities  are  coordinated  across  the 

acquisition  organization. 

Goal  3  Information  relating  to  the  use  of  the  acquisition  organization's  standard 

software  acquisition  process  by  the  software  acquisition  projects  is 
collected,  analyzed,  and  made  accessible. 

Commitment  to  perform 


Commitment  1  The  acquisition  organization  has  a  written  policy  for  software  acquisition 
process  definition  and  maintenance  activities. 
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Level  3:  The  Defined  Level 


Process  Definition  and  Maintenance 


Commitment  2 


Commitment  3 


This  policy  typically  specifies  that: 

1 .  A  software  acquisition  process  group  is  established  and  is  responsible  for  the  acquisition 
organization-level  software  acquisition  process  activities  and  coordinating  these  activities 
with  the  projects. 

2.  A  standard  software  acquisition  process  is  defined  for  the  acquisition  organization. 

The  acquisition  organization’s  standard  software  acquisition  process  may  contain  more  than  one  process. 

A  choice  of  processes  may  be  necessary  to  address  a  project’s  unique  acquisition  environment. _ 

3.  The  software  acquisition  process  used  by  the  projects  is  selected  fi*om  the  acquisition 
organization's  standard  software  acquisition  process  and  is  tailored  based  on  a  project's 
specific  acquisition  environment. 

4.  The  software  acquisition  process  assets  are  maintained. 


The  acquisition  organization’s  software  acquisition  process  assets  include: 
the  acquisition  organization's  standard  software  acquisition  process, 

guidelines  and  criteria  for  the  projects'  tailoring  of  the  acquisition  organization’s  standard  software 
acquisition  process, 

descriptions  of  the  standard  acquisition  strategies  approved  for  use,  and 

the  software  acquisition  process  repository.  _ 

5.  Improvements  to,  lessons  learned,  and  other  useful  information  on  each  project's  defined 
software  acquisition  process,  tools,  and  methods  are  collected  and  made  accessible  to  other 
projects. 

6.  Information  collected  from  the  projects  is  reviewed,  analyzed,  and  used  to  improve  the 
acquisition  organization’s  standard  software  acquisition  process. 

Organization  management  sponsors  the  acquisition  organization's 
activities  for  process  definition  and  maintenance. 

Organization  management  establishes: 

1 .  Long-term  plans  and  commitments  for  funding,  stafiSng,  and  other  resources,  and  its 
commitment  to  these  software  acquisition  process  activities. 

2.  Strategies  for  managing  and  implementing  the  activities  for  process  definition  and 
maintenance. 

Responsibility  for  process  definition  and  maintenance  activities  is 
designated. 
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Process  Definition  and  Maintenance 


Levels:  The  Defined  Level 


Ability  1 
Ability  2 


Ability  3 

Ability  4 

Activity  1 


Ability  to  perform 


A  group  that  is  responsible  for  the  acquisition  organization's  process 
definition  and  maintenance  activities  exists. 

Adequate  resources  are  provided  for  process  definition  and  maintenance 
activities. 

Resources  include: 

1.  Funding. 

2.  Staff. 

3.  Equipment. 

4.  Tools. 

Members  of  the  software  acquisition  process  group  have  experience  or 
receive  required  training. 

Ejq)erience  means,  for  example,  having  participated  in  a  software  acquisition  management 
role  on  at  least  one  project  and  membership  in  an  active  process  group,  such  as  a  software 
engineering  process  group,  for  at  least  one  year. _ 


Refer  to  the  Training  Program  key  process  aiea  for  a  description  of  training  practices. 

Project  team  members  receive  training  on  the  acquisition  organization's 
standard  software  acquisition  process  and  their  roles  in  this  process. 

Refer  to  the  Training  Program  key  process  area  for  a  description  of  training  practices. 

Activities  performed 


The  acquisition  organization  performs  its  activities  in  accordance  with  its 
documented  process  definition  and  maintenance  plans. 

The  plan(s)  should  be  consistent  with  other  acquisition  organization  plans.  Inputs,  such 
as  action  plans  fi'om  software  acquisition  process  appraisals,  strategic  and  operational 
business  plans,  and  acquisition  organization  improvement  initiatives,  should  be  considered 
in  the  development  of  and  subsequent  updates  to  the  plan. _ 
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Levels:  The  Defined  Level 


Process  Definition  and  Maintenance 


Activity  2 


Activity  3 


The  plans  typically  cover: 

1 .  The  objectives  of  the  acquisition  organization's  process  definition  and  maintenance 
activities. 

Objectives  define  the  direction  and  general  timing  for  the  acquisition  organization's  process  definition  and 
maintenance  activities.  Objectives  may  specify  particular  areas  for  improvement  focus,  such  as  coitort 
perfonnance  management  and  procedural  guidance  and  the  coverage  and  time  intervals  for  periodic 
appraisals  of  the  software  acquisition  process. _ _ _ _ _ 

2.  The  process  definition  and  maintenance  activities  to  be  performed  and  the  schedule  for  these 
activities. 

3 .  The  groups  and  individuals  responsible  for  the  process  definition  and  maintenance  activities. 

4.  The  resources  required  to  perform  the  process  definition  and  maintenance  activities. 

5.  The  procedures  to  be  followed  in  performing  the  process  definition  and  maintenance 
activities. 

6.  A  required  review  and  approval  by  acquisition  organization  management. 

7 .  Management  and  control  of  the  plan(s). 

Refer  to  Activity  3  of  the  Software  Acquisition  Planning  key  process  area. 

The  acquisition  organization’s  standard  software  acquisition  process  is 
denned  and  maintained  in  accordance  with  its  documented  process 
definition  and  maintenance  plans. 

These  plans  t}pically  require  that: 

1 .  The  acquisition  organization's  standard  software  acquisition  process  satisfies  the  software 
acquisition  policies,  process  standards,  product  standards,  and  legal  requirements  imposed 
on  the  organization,  as  appropriate. 

2.  State-of-the-practice  software  acquisition  tools  and  methods  are  incorporated  into  the 
acquisition  organization's  standard  software  acquisition  process,  as  appropriate. 

3.  A  software  acquisition  cost  model(s)  for  project  planning  and  estimating  is  developed  and 
maintained  as  part  of  the  acquisition  organization's  standard  software  acquisition  process. 

The  software  acxjuisition  cost  model(s)  includes  both  a  software  cost  model(s)  for  estimating  the  contractor's 
software  effort,  schedule,  and  cost  and  a  model(s)  for  estimating  the  project  team's  effort,  schedule,  and  cost. 

4.  The  software  acquisition  process  group  reviews,  approves,  manages,  and  controls  any 
changes  to  the  standard  software  acquisition  process. 

The  acquisition  organization’s  standard  software  acquisition  process  is 
appraised  periodically  and  action  plans  developed  to  address  the  findings 
of  the  appraisal. 
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Process  Definition  and  Maintenance 


Level  3;  The  Defined  Level 


Activity  4 


Activity  5 


Activity  6 


The  action  plans  typically  identify: 

1 .  Which  appraisal  findings  will  be  addressed,  their  priority,  and  the  schedule  for  addressing 
them. 

2.  Guidelines  for  implementing  changes  to  address  the  findings. 

3 .  Responsibility  for  implementing  the  changes. 

4.  Closure  plans  for  implementing  the  changes. 

5.  Appraisal  finding.s  that  will  not  be  addressed  and  rationale  for  not  doing  so. 

The  acquisition  organization's  and  projects'  activities  for  defining  and 
maintaining  their  software  acquisition  processes  are  coordinated  at  the 
oi^anization  level. 

Guidelines  and  criteria  for  a  project's  selection  and  tailoring  of  the 
acquisition  organization's  standard  software  acquisition  process  are 
developed  and  maintained. 

The  guidelines  and  criteria  typically  cover: 

1 .  Selecting  and  tailoring  the  acquisition  organization's  standard  software  acquisition  process 
and  software  acquisition  strategy  to  accommodate  the  project's  characteristics. 

2.  Standards  for  documenting  the  project's  defined  software  acquisition  process. 

3.  Procedures  for  obtaining  permission  to  deviate  fi’om  the  acquisition  organization's  standard 
software  acquisition  process. 

An  organizational  repository  of  software  acquisition  process  information 
is  established,  managed,  controlled,  and  maintained  to  support  process 
definition  and  maintenance  activities. 

1 .  Information  includes  both  data  about  software  acquisition  process  and  work  products,  and 
software  acquisition  process-related  documentation. 


Software  acquisition  process  and  work  products  data  include: 
cost  model  used; 

project  software  measurements  (planned  and  actual);  and 
software  size,  effort  schedule,  and  defects. _ 


Some  examples  of  software  acquisition  process-related  documentation  include: 

description  of  a  project's  defmed  software  acquisition  process  and 
a  project's  software  acquisition  doaimentation  (e.g.,  acquisition  strategy, 
evaluation,  solicitation,  and  software  acquisition  management  plans). _ 
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Level  3 :  The  Defined  Level 


Process  Definition  and  Maintenance 


Activity  7 


Measurement  1 


2.  Information  on  the  acquisition  organization's  and  projects'  software  acquisition  processes 
and  work  products  is  collected. 

3.  Candidate  information  items  are  reviewed  and  appropriate  items  are  included  in  the 
repository. 

4.  Information  items  are  catalogued  for  easy  access. 

5.  The  repository  contents  are  made  available  for  use  by  the  software  acquisition  projects  and 
other  software  acquisition-related  groups. 

6.  The  use  of  each  information  item  is  reviewed  periodically  for  currency,  relevancy,  and 
validity,  and  the  results  are  used  to  maintain  the  repository  contents. 

7.  User  access  to  the  repository  contents  is  controlled  to  ensure  completeness,  integrity,  and 
accuracy  of  the  information. 

8.  Access  is  limited  to  those  who  have  a  need  to  enter,  change,  view,  analyze,  or  extract 
information.  Sensitive  information  is  protected  and  access  to  this  information  is 
appropriately  controlled. 

Project  teams  are  informed  of  the  acquisition  organization's  and  projects' 
activities  for  process  definition  and  maintenance. 

Some  examples  of  means  to  inform  project  teams  include: 

electronic  bulletin  boards  relating  to  software  acquisition  process, 

working  groups, 

information  exchange  meetings, 

surveys, 

process  improvement  teams,  and 

informal  discussions. _ 


Measurement  and  analysis 


Measurements  are  made  and  used  to  determine  the  status  of  the  process 
definition  and  maintenance  activities  and  resultant  products. 

Some  examples  of  measurements  include: 

effort  expended; 
funds  expended: 

progress  towards  completion  of  process  definition  and  maintenance 
planning,  defining  the  acquisition  organization's  standard  software 
acquisition  process,  defining  guidelines  for  tailoring  the  standard  software 
acquisition  process,  establishing  the  software  acquisition  process  repository, 
and  establishing  vehicles  for  disseminating  software  acquisition 
information;  and 

completion  of  milestones. _ 
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Process  Definition  and  Maintenance 


Levels:  The  Defined  Level 


Verification  1 


Verifying  implementation 


Process  definition  and  maintenance  activities  are  reviewed  by  acquisition 
organization  management  on  a  periodic  basis. 

The  primary  purpose  of  these  reviews  by  acquisition  organization  management  is  to 
provide  awareness  of,  and  insight  into,  process  definition  and  maintenance  activities  at  an 
appropriate  level  of  abstraction  and  in  a  timely  manner.  The  reviews  verify  that  acquisition 
organization  policy  is  being  implemented.  The  time  between  reviews  should  satisfy  the 
needs  of  the  organization  and  may  be  lengthy,  as  long  as  adequate  mechanisms  for 
exception  reporting  are  available.  _ 


At  a  minimum,  these  reviews  verify  that: 

1 .  Progress  and  status  of  the  activities  to  define  and  improve  the  software  acquisition  process 
are  reviewed  against  the  plan. 

2  Conflicts  and  issues  not  resolved  at  lower  levels  are  addressed. 

3  Action  items  are  assigned,  reviewed,  and  tracked  to  closure. 

4  A  summary  report  from  each  review  is  prepared  and  distributed  to  affected  groups  and 
individuals. 
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Level  3 ;  The  Defined  Level 


Project  Performance  Management 

Project  Performance  Management _ 

a  key  process  area  for  Level  3:  Defined _ 

The  purpose  of  Project  Performance  Management  is  to  manage  the  software  acquisition  project 
according  to  a  defined  software  acquisition  process. 

Project  Performance  Management  involves  developing  the  project's  defined  software  acquisition 
process  and  managing  the  acquisition  using  this  defined  process.  The  project's  defined  software 
acquisition  process  is  tailored  from  the  acquisition  organization's  standard  software  acquisition 
process  to  address  specific  attributes  of  the  project. 

The  project's  management  plans  are  based  on  the  project's  defined  software  acquisition  process. 
These  plans  describe  how  the  project's  defined  software  acquisition  process  will  be  implemented 
and  managed. 

The  basic  practices  for  estimating,  planning,  and  tracking  a  software  acquisition  project  are 
established  in  the  Software  Acquisition  Planning,  Project  Management,  and  Contract  Tracking 
and  Oversight  key  process  areas.  The  emphasis  in  Project  Performance  Management  at  Level  3 
shifts  from  reacting  to  acquisition  problems  and  issues  to  anticipating  these  problems  and  acting 
to  mitigate  the  risk. 

Goals 


Goal  1  The  project  is  managed  according  to  a  coherent  defined  software 

acquisition  process. 

Goal  2  Effective  communication  and  teamwork  among  affected  groups  esdsts. 

Goal  3  An  integrated  management  approach  is  used  to  achieve  project 

management's  software  acquisition  objectives. 

Commitment  to  perform 


Commitment  1  The  acquisition  organization  has  a  written  policy  for  the  planning  and 
managing  of  the  project's  software  acquisition  activities. 
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Project  Performance  Management 


Level  3:  The  Defined  Level 


Ability  1 


Activity  1 


Activity  2 


This  policy  typically  specifies  that: 

1 .  The  project's  defined  software  acquisition  process  is  developed  and  documented  by  tailoring 
the  acquisition  organization's  standard  software  acquisition  process  according  to  approved 
tailoring  guidelines. 

Refer  to  Activity  5  of  the  Process  Definitio?i  and  Maintenance  key  process  area. 

2.  The  project's  software  acquisition  activities  are  planned  and  performed  according  to  the 
project’s  defined  software  acquisition  process. 

3 .  Appropriate  project  measurement  data  are  collected  and  stored  by  the  project  team 
according  to  the  acquisition  organization's  software  acquisition  process  repository 
requirements. 

Ability  to  perform 


The  individuals  responsible  for  managing  the  software  acquisition  project 
activities  have  experience  or  receive  required  training. 

Experience  means,  for  example,  having  participated  in  a  software  acquisition  management 
role  on  at  least  one  project  and  having  experience  in  the  domain  of  the  application  being 
acquired.  Additionally,  some  individuals  should  have  experience  in  project  planning, 
organizing,  controlling,  budgeting,  and  scheduling. _ _ 


Refer  to  Activity  3  of  the  Training  Program  key  process  area. 

Activities  performed 


The  project’s  defined  software  acquisition  process  is  developed  and 
documented  by  tailoring  the  acquisition  organization’s  standard  software 
acquisition  process  according  to  the  organization’s  tailoring  guidelines. 

Refer  to  Activity  5  of  the  Process  Definition  and  Maintenance  key  process  area. 

The  project  team  develops  and  maintains  the  Project  Management  Plan 
in  accordance  with  the  acquisition  organization's  standard  software 
acquisition  process. 

Refer  to  the  Software  Acquisition  Planning,  Project  Management,  and  Contract  Tracking  and 
Oversight  key  process  areas. 
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Level  3:  The  Defined  Level 


Project  Performance  Management 


The  Project  Management  Plan  typically  addresses: 

1 .  Technical  requirements  from  a  reasoned  analysis  of  the  end  user's  needs. 

2.  Management  of  solicitation  and  proposal  evaluation  plans. 

3.  Management  of  transition  to  support  plans. 

4.  Provisions  for  gathering,  analyzing,  and  reporting  measurement  data  needed  to  manage  the 
software  acquisition  project. 

5.  Activities  for  software  estimating,  planning,  and  tracking  related  to  the  key  tasks  and  work 
products  of  the  project’s  defined  software  acquisition  process. 

6.  Readiness  and  completion  criteria  established,  documented,  and  used  to  authorize  initiation 
and  determine  completion  of  key  tasks. 

7.  Critical  dependencies  and  paths  that  are  to  be  reflected  in  the  schedule  and  tracked  on  a 
regular  basis. 

8.  Documented  criteria  indicating  when  to  review  and  revise  the  Project  Management  Plan. 

9.  Review  and  use  of  software  acquisition  management  lessons  learned,  recorded,  and  stored  in 
the  acquisition  organization's  software  acquisition  process  repository  to  estimate,  plan,  track, 
and  re-plan  the  software  acquisition  project. 

Refer  to  Activity  6  of  the  Process  Definition  and  Maintenance  key  process  area, 

10.  Staffing  plan  that  addresses  the  software  acquisition  project's  needs  for  individuals  with 
special  skills  and  acquisition  domain  knowledge. 

1 1 .  Training  needs  identified  and  documented  to  fit  the  specific  needs  of  the  software  acquisition 
project. 

Refer  to  the  Training  Program  key  process  area. 

12.  Software  acquisition  management  plans  and  processes  to  be  followed  in  interacting  with 
other  groups. 

13.  Risk  management  planning. 

Refer  to  Activity  2  of  the  Acquisition  Risk  Management  key  process  area. 

14.  Resources  to  accomplish  the  requirements  of  the  Project  Management  Plan. 

Activity  3  The  project  team’s  software  acquisition  management  activities  are 

performed  in  accordance  with  the  Project  Management  Plan. 

Activity  4  The  project’s  defined  software  acquisition  process  is  revised  as  required 

to  remain  consistent  with  current  project  objectives. 
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Project  Performance  Management 


Level  3 :  The  Defined  Level 


Activity  5 
Activity  6 

Activity  7 
Activity  8 

Activity  9 

Activity  10 

Activity  11 

Measurement  1 


The  project  team  coordinates  its  activities  with  other  organizations  and 
activities  supporting  the  project. 

The  acquisition  organization's  software  acquisition  process  repository  is 
used  for  project  planning,  estimating,  and  management. 

Refer  to  Activity  6  of  the  Process  Definition  and  Maintenance  key  process  area. 

Critical  dependencies  are  identified,  negotiated,  and  managed. 

The  project  team  performs  periodic  reviews  to  ensure  current  and 
projected  needs  of  the  end  user  will  be  satisfied. 

Measurements  are  used  to  determine  project  team  performance  and 
trends  analyzed. 

Trend  analysis  relies  on  internal  and  external  data. 


The  project  team  identifies  and  analyzes  risks  and  identifies  specific  risk 
handling  actions  for  those  risks. 

Refer  to  Activity  3  of  Software  Acquisition  Planning,  Activity  2  of  Contract  Petformance 
Management,  and  Activity  5  of  Acquisition  Risk  Management  key  process  areas. 

The  project  team's  software  acquisition  lessons  learned  are  identified, 
documented,  and  entered  into  the  acquisition  organization's  software 
acquisition  process  repository. 

Measurement  and  analysis 


Measurements  are  made  and  used  to  determine  the  status  of  the  project 
performance  management  activities  and  resultant  products. 

Some  examples  of  measiirements  include: 

eiSfort  expended; 
funds  expended; 

progress  towards  completion  of  the  Project  Management  Plan,  updates 
to  the  Project  Management  Plan,  establishing  a  corrective  action  system, 
updating  the  software  acquisition  process  repository;  and 
completion  of  milestones. _ 
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Level  3 :  The  Defined  Level 


Project  Performance  Management 


I 


Verification  1 


Verification  2 


I 


Verifying  implementation 


Project  performance  management  activities  are  reviewed  by  acquisition 
organization  management  on  a  periodic  basis. 

The  primary  purpose  of  these  reviews  by  acquisition  organization  management  is  to 
provide  awareness  of,  and  insight  into,  project  performance  management  activities  at  an 
appropriate  level  of  abstraction  and  in  a  timely  manner.  The  reviews  verify  that  acquisition 
organization  policy  is  being  implemented.  The  time  between  reviews  should  satisfy  the 
needs  of  the  organization  and  may  be  lengthy,  as  long  as  adequate  mechanisms  for 
exception  reporting  are  available. _ _ _ _ _ 


Project  performance  management  activities  are  reviewed  by  the  project 
manager  on  both  a  periodic  and  event-driven  basis. 

The  review  should  include  the  activities  performed  as  specified  in  the  Project  Management 
Plan. _ _ _ _ 
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Contract  Performance  Management 


Level  3:  The  Defined  Level 


Contract  Performance  Management _ 

a  key  process  area  for  Level  3:  Defined  _ 

The  purpose  of  Contract  Performance  Management  is  to  implement  a  defined  contract 
management  process,  the  objective  of  which  is  to  acquire  software  products  and  services  that 
satisfy  contract  requirements. 

Contract  Performance  Management  involves  appraising  the  contractor's  software  engineering 
performance  and  the  quality  of  the  evolving  products  and  ongoing  services.  Based  on  the  results 
of  the  appraisals,  the  acquisition  may  be  adjusted.  The  process  includes  evaluation  of  final 
products  and  services  to  determine  satisfaction  of  contractual  requirements.  The  emphasis  in 
contract  performance  management  is  to  be  proactive  regarding  contractor  performance  and 
contract  compliance  issues  and  to  minimize  the  effects  of  these  issues.  Additional  activities 
include  contributing  to  the  project's  risk  management  activities,  fostering  an  environment  of 
mutual  cooperation  with  the  contractor,  and  identifying  improvements  to  the  contract 
performance  management  process. 

The  contract  performance  management  process  integrates  contract  performance  management 
activities  with  other  project  management  activities.  Contract  Performance  Management  builds  on 
the  Contract  Tracking  and  Oversight  and  Evaluation  key  process  areas.  Contract  performance 
management  begins  when  the  contract  is  awarded  and  ends  at  the  conclusion  of  the  contract  s 
period  of  performance. 


Goals 


Goal  1  Contract  performance  management  activities  are  conducted  in  a  manner 

that  ensures  satisfaction  of  software  contractual  requirements. 

Goal  2  The  quality  of  contractor  performance,  products,  and  services  is 

appraised  throughout  the  contract's  period  of  performance  to  identify 
risks  and  take  action  to  mitigate  those  risks  as  early  as  possible. 

Goal  3  A  cooperative  and  productive  environment  among  the  project  team,  the 

end  user,  and  the  contractor  exists. 
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Level  3 :  The  Defined  Level _ Contract  Performance  Management 

Commitment  to  perform 


Commitment  1  The  acquisition  organization  has  a  written  policy  for  the  performance  of 
contract  performance  management  activities. 

This  policy  typically  specifies  that: 

1 .  Contract  performance  management  activities  are  performed  in  accordance  with  the  project's 
defined  software  acquisition  process. 

2.  Appropriate  tools  and  methodologies  are  used  to  evaluate  the  products  and  services. 

3.  Risk  analysis  and  management  are  included  as  part  of  the  contract  performance  management 
activities. 

4.  Software  products  and  services  must  pass  a  successful  evaluation  of  contract  requirements 
before  sj^stem  acceptance. 

5.  Software  acceptance  is  dependent  on  the  successful  completion  of  operational  evaluation. 

6.  Testing  requirements  and  measurable  acceptance  criteria  are  established  before  the  request 
for  proposals  is  released. 

7.  The  contractor  is  encouraged  to  establish  a  rigorous  engineering  evaluation  process. 

8.  The  project's  software  evaluation  planning  is  updated  to  reflect  changes  to  the  requirements. 

Ability  to  perform 


Ability  1  A  group  that  is  responsible  for  performing  contract  performance 

management  activities  exists. 

Ability  2  Individuals  performing  contract  performance  management  activities  have 

experience  or  receive  required  training  in  related  software  acquisition 
disciplines  and  contract  performance  management  procedures. 


Experience  means,  for  example,  having  participated  on  more  than  one  software 
development  project  including  appraising  the  contractor's  planning  documents,  software 
engineering  process,  products,  and  services;  having  knowledge  of  current  software 
development  technologies;  and  having  knowledge  in  the  domain  of  the  application  being 
acquired. _ 


Training  includes  areas  of  software  evaluation,  data  reduction,  and  analysis  techniques. 
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Contract  Performance  Management 


Levels;  The  Defined  Level 


Activity  1 


Activity  2 


Activity  3 


Activities  performed 


The  project  team  performs  its  activities  in  accordance  with  its 
documented  contract  performance  management  plans. 

In  addition  to  the  planning  information  called  for  in  the  Contract  Tracking  and  Oversight  key 
process  area,  these  plans  also  typically  cover: 

1 .  The  guidelines  and  criteria  used  in  defining  the  project's  contract  performance  management 
activities. 

2.  The  activities  to  be  performed  and  the  schedule  to  perform  the  activities. 

3 .  Risk  management. 

Refer  to  Activity  3  of  Software  Acquisition  Planning  and  Activity  1  of  the  Contract  Tracking 
and  Oversight  key  process  areas. 

The  contractor’s  software  engineering  process  is  appraised  according  to 
the  project's  defined  software  acquisition  process. 

Typical  activities  include: 

1 .  The  contractor’s  software  engineering  process,  practices,  methodologies,  and  procedures  are 
continually  appraised  for  effectiveness  and  for  compliance  with  contractual  requirements. 

2.  The  contractor's  quality  assurance,  configuration  management,  corrective  action,  and  risk 
management  systems  and  processes  are  appraised  for  compliance  with  standards  and  plans 
to  ensure  that  associated  results  support/promote  attainment  of  contract  objectives  and 
compliance  with  contractual  requirements. 

3.  Trend  analysis  of  the  contractor's  software  engineering  process  is  performed  to  detect  issues 
in  satisfying  contractual  requirements  as  early  as  possible. 

Results  of  the  contractor's  engineering  activities  are  appraised  according 
to  the  project’s  defined  software  acquisition  process. 

Some  of  the  appraisals  conducted  verify  that: 

1 .  The  software  requirements  are  being  developed,  documented,  maintained,  and  verified 
according  to  the  contractor's  software  engineering  process  and  are  traceable  to  higher  level 
requirements. 

2.  The  software  architecture  is  feasible  and  will  satisfy  future  system  growth  and  reuse  needs. 

3.  The  software  design  is  developed,  documented,  maintained,  and  verified  according  to  the 
contractor's  software  engineering  process. 
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Level  3;  The  Defined  Level 


Contract  Performance  Management 


Activity  4 


Activity  5 


Activity  6 


Activity  7 


4.  The  software  is  developed  and  documented  according  to  the  contractor's  software 
engineering  process. 

5.  The  documentation  that  will  be  used  to  operate  and  support  the  software  is  developed  and 
maintained  according  to  the  contractor's  softw'are  engineering  process. 

6.  The  integration  of  COTS  with  developed  software  is  accomplished  in  accordance  with  the 
contractor's  software  engineering  process  and  planning  documents. 

Measurements  from  appraisals  are  used  to  evaluate  the  contractor's 
performance  and  trends  analyzed. 

Trend  analysis  can  rely  on  internal  and  external  data. 


As  understanding  of  the  software  engineering  process,  products,  and 
services  improves,  the  project  team  may  propose  changes  to  the  software 
products  or  services,  process  plans,  and  activities. 

1 .  The  project  team  determines  the  impact  of  changes  before  the  changes  are  implemented. 

2.  Changes  to  all  software  products  and  services  are  coordinated  within  the  project  team  and 
communicated  to  other  affected  groups. 

3.  Adjustments  that  affect  contractual  requirements  are  made  through  official  contracting 
channels. 

The  end  user  periodically  participates  in  the  evaluation  of  evolving 
software  products  and  services  to  determine  the  satisfaction  of 
operational  requirements. 

Refer  to  Activity  5  of  the  Evaluation  key  process  area. 

Contract  performance  management  activities  are  performed  to  foster  a 
cooperative  environment  between  the  project  team  and  the  contractor. 

Typical  activities  include: 

1 .  Supporting  a  mutual  understanding  of  the  contract's  requirements  between  the  project  team 
and  the  contractor. 

2.  Maintaining  ongoing  communications  between  the  project  team  and  the  contractor  at 
appropriate  levels. 

3 .  Facilitating  access  to  information  regarding  the  status  of  the  contractor's  software 
performance  and  accomplishments. 

4.  Allowing  the  contractor  to  manage  the  software  engineering  efforts,  including  engineering 
evaluation,  with  minimal  project  team  interference. 
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Contract  Performance  Management 


Level  3:  The  Defined  Level 


Measurement  1 


Verification  1 


Verification  2 


5.  Promoting  the  joint  development  of  solutions  to  issues  by  the  project  team  and  the 
contractor. 

6.  Requiring  that  the  project  team  satisfies  its  commitments  to  the  contractor,  such  as  review  of 
contractor-generated  documentation  and  timely  feedback  of  the  results  of  project  team 
evaluations  of  contractor  performance,  products,  and  services. 

7.  Maintaining  mutual  understanding  of  methods  to  administer  the  contract. 


Some  examples  of  areas  to  be  addressed  include: 

maintenance  of  bi-directional,  non-intrusive  communications  between  the  project  team  and  the  contractor, 
how  issues  and  concerns  not  resolvable  at  lower  levels  will  be  decided; 
methods  of  identifying  and  mitigating  risks;  and 

the  use  of  both  software  process  and  product  measurements  as  a  common  basis  of  communication  to 
understand  the  requirements  and  the  status  of  the  project. _ _ 


Measurement  and  analysis 


Measurements  are  made  and  used  to  determine  the  status  of  the  contract 
performance  management  activities  and  resultant  products. 

Some  examples  of  measurements  include; 

effort  expended; 
funds  expended; 

progress  towards  completion  of  contract  performance 
management  planning,  appraisals,  evaluations,  and  risk 
analyses;  and 

completion  of  milestones. _ 


Verifying  implementation 


Contract  performance  management  activities  are  reviewed  by  acquisition 
organization  management  on  a  periodic  basis. 


The  primary  purpose  of  these  reviews  by  acquisition  organization  management  is  to 
provide  awareness  of,  and  insight  into,  contract  performance  management  activities  at  an 
appropriate  le\^l  of  abstraction  and  in  a  timely  manner.  The  reviews  verify  that  acquisition 
organization  policy  is  being  implemented.  The  time  between  reviews  should  satisfy  the 
needs  of  the  organization  and  may  be  lengthy,  as  long  as  adequate  mechanisms  for 
exception  reporting  are  available. _ 


Contract  performance  management  activities  are  reviewed  by  the  project 
manager  on  both  a  periodic  and  event-driven  basis. 
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Levels:  The  Defined  Level _  Acquisition  Risk  Management 

Acquisition  Risk  Management _ 

a  key  process  area  for  Level  3:  Defined _ _ 

The  purpose  of  Acquisition  Risk  Management  is  to  identify  risks  as  early  as  possible,  adjust  the 
acquisition  strategy  to  manage  those  risks,  and  develop  and  implement  a  risk  management  process 
as  an  integral  part  of  the  acquisition  organization's  standard  software  acquisition  process. 
Acquisition  risk  management  begins  with  the  process  of  defining  the  system  need  and  terminates 
when  the  software  acquisition  is  completed.  Acquisition  risk  management  becomes  an  integral 
part  of  the  solicitation,  project  performance  management,  and  contract  performance  management 
processes. 

Acquisition  risk  management  is  a  two-part  process.  First,  the  software  acquisition  strategy 
identifies  the  risks  associated  with  the  acquisition  of  the  system  and  the  approach  is  planned  based 
on  those  risks.  Second,  a  process  is  employed  to  manage  the  risks  throughout  the  acquisition. 

Risk  identification  includes  categorization  of  the  risk  based  on  historical  data  and  estimates  to 
determine  the  impact  of  each  risk  on  quality,  performance,  schedule,  and  cost.  The  risks  are 
analyzed  to  determine  their  impact  on  acquisition  strategy  and  software  engineering.  Analysis 
includes  determining  the  driver  of  each  risk  area  and  the  impact  of  the  risk  so  that  risk  handling 
strategies  may  be  proposed  and  tested. 

Acquisition  risk  management  is  planned  through  the  Software  Acquisition  Risk  Management  Plan 
which  details  the  processes  to  take  place  in  acquisition  planning  and  software  acquisition 
management.  The  Software  Acquisition  Risk  Management  Plan  describes  the  overt  management 
actions  and  procedures  to  identify,  analyze,  and  rank  order  risks,  and  the  risk  handling  methods  to 
be  applied. 


Goals 


Goal  1  Software  acquisition  risk  management  is  an  integral  part  of  the  project's 

defined  software  acquisition  process. 

Goal  2  The  project  identifies  and  deals  with  risk  in  a  positive  manner,  such  that 

identification  is  recognized  and  rewarded,  and  results  in  efiective  risk 
handling. 
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Acquisition  Risk  Management 


Level  3:  The  Defined  Level 


Commitment  1 


Commitment  2 

Ability  1 
Ability  2 


Ability  3 


Commitment  to  perform 


The  acquisition  organization  has  a  written  policy  for  the  management  of 
software  acquisition  risk. 

This  policy  typically  specifies  that: 

1 .  Risk  identification  is  performed  throughout  the  project  life  cycle  in  accordance  with  the 
project's  defined  software  acquisition  process. 

2.  Risk  management  activities  involve  the  project  team,  end  user,  and  the  contractor  as 
appropriate. 

3.  Risk  management  is  a  positive  and  proactive  part  of  software  acquisition. 

4.  Risk  information  is  communicated  throughout  the  project  team. 

Responsibility  for  software  acquisition  risk  management  activities  is 
designated. 

Ability  to  perform 


A  group  that  is  responsible  for  coordinating  software  acquisition  risk 
management  activities  exists. 

Adequate  resources  are  provided  for  software  acquisition  risk 
management  activities. 

Resources  include: 

1 .  Funding. 

2.  Staff. 

3.  Equipment. 

4.  Tools. 

Individuals  performing  software  acquisition  risk  management  activities 
have  experience  or  receive  required  training. 

Experience  means,  for  example,  having  participated  in  a  software  acquisition  management 
role  and  having  applied  risk  management  techniques  on  at  least  one  project  and  having 
experience  in  the  domain  of  the  application  being  acquired. _ 
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Level  3 ;  The  Defined  Level 


Activity  1 


Activity  2 


Activity  3 
Activity  4 


Activity  5 


Acquisition  Risk  Management 

Activities  performed 


Software  acquisition  risk  management  activities  are  integrated  into 
software  acquisition  planning. 


Risk  manapemant  includes  risk  identification,  analysis,  planning,  tracking,  and  controlling. 


The  acquisition  strategy  evolves  based  on  risk  identification  and  analysis. 


Refer  to  Activity  3  of  the  Software  Acquisition  Planning  key  process  area. 

The  Software  Acquisition  Risk  Management  Plan  is  developed  in 
accordance  with  the  project’s  defined  software  acquisition  process. 

The  plan  typically  provides  for: 

1 .  The  processes  that  the  project  team  will  follow  for  risk  management. 

2.  Reporting  on  risk  management  activities. 

3 .  Plans  for  handling  identified  risks. 

4.  The  process  for  managing  and  controlling  the  Software  Acquisition  Risk  Management  Plan. 

5.  Resource  requirements. 

The  project  team  performs  its  software  acquisition  risk  management 
activities  in  accordance  with  its  documented  plans. 

Risk  management  is  conducted  as  an  integral  part  of  the  solicitation, 
project  performance  management,  and  contract  performance 
management  processes. 

Refer  to  Activity  1  of  Solicitation,  Activities  2  and  10  of  Project  Performance  Management,  and 
Activities  1  and  2  of  the  Contract  Performance  Management  key  process  areas. 

Software  acquisition  risk  handling  actions  are  tracked  and  controlled 
until  the  risks  are  mitigated. 

Risk  handling  actions  typically  include; 

1 ;  Tracking  the  status  of  the  risk  handling  actions  against  the  plan. 

2.  Reporting  of  the  updated  assessments  of  the  risks  and  status  of  the  risk  handling  actions. 

3.  Identification  of  corrective  actions  to  be  performed  and  updated  risk  handling  actions 
required. 
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Acquisition  Risk  Management 


Level  3;  The  Defined  Level 


Measurement  1 


Verification  1 


Verification  2 


4.  Periodic  reviews  of  risk  handling  activities. 

Measurement  and  analysis 


Measurements  are  made  and  used  to  determine  the  status  of  the 
acquisition  risk  management  activities  and  resultant  products. 

Some  examples  of  measurements  include: 

effort  expended, 
funds  expended, 

status  of  development  of  the  Software  Acquisition  Risk  Management  Plan, 
status  of  risks  (e.g.,  Top-Ten  List), 
status  of  risk  management  actions,  and 

status  of  the  of  risk  management  analysis  actions. _ 


Verifying  implementation 


Acquisition  risk  management  activities  are  reviewed  by  acquisition 
organization  management  on  a  periodic  basis. 


The  primaty  purpose  of  these  reviews  by  acquisition  organization  management  is  to 
provide  awareness  of,  and  insight  into,  acquisition  risk  management  activities  at  an 
appropriate  level  of  abstraction  and  in  a  timely  manner.  The  reviews  verify  that  acquisition 
organization  policy  is  being  implemented.  The  time  between  reviews  should  satisfy  the 
needs  of  the  organization  and  may  be  lengthy,  as  long  as  adequate  mechanisms  for 
exception  reporting  are  available. _ 


Acquisition  risk  management  activities  are  reviewed  by  the  project 
manager  on  both  a  periodic  and  event-driven  basis. 


Each  review  should  include  the  activities  performed  as  specified  in  the  Software 
Acquisition  Risk  Management  Plan. _ 
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Training  Program _ 

a  key  process  area  for  Level  3:  Defined _ 

The  purpose  of  Training  Program  is  to  develop  the  skills  and  knowledge  of  individuals  so  they  can 
perform  their  software  acquisition  roles  effectively  and  efficiently. 

Training  Program  involves  appraisal  of  training  requirements  at  the  acquisition  organization, 
project,  and  individual  levels.  The  acquisition  organization  surveys  its  current  and  future  skill 
needs  and  determines  how  these  skills  will  be  obtained.  Current  weaknesses  of  the  acquisition 
organization  are  understood  and  plans  are  developed  to  systematically  address  the  weaknesses. 

Some  skills  are  effectively  and  efficiently  imparted  through  informal  vehicles,  whereas  other  skills 
need  more  formal  training  vehicles  to  be  effectively  and  efficiently  imparted.  The  appropriate 
vehicles  are  selected  and  used. 

Members  of  the  acquisition  organization  are  schooled  in  the  standard  software  acquisition 
process,  the  project,  the  domain,  and  in  the  skills  and  knowledge  needed  to  perform  their  jobs 
effectively.  Members  effectively  use,  or  are  prepared  to  use,  the  capabilities  and  features  of  the 
existing  and  planned  work  environment.  The  project  teams  become  more  effective  through  a 
better  understanding  of  their  work  processes. 

This  key  process  area  covers  the  group  that  is  performing  the  organization's  training  function. 

The  processes  identifying  specific  training  topics  (i.e.,  knowledge  or  skills  needed)  are  contained 
in  the  common  feature  "Ability  to  perform"  of  the  individual  key  process  areas. 

Goals 


Goal  1  Training  Program  activities  are  planned. 

Goal  2  Required  training  is  identified  and  provided. 

Goal  3  The  training  program  fully  supports  the  acquisition  organization's 

standard  software  acquisition  process. 

Commitment  to  perform 


Commitment  1  The  organization  has  a  written  policy  for  satisfying  its  training  needs. 
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Levels:  The  Defined  Level 


Commitment  2 


Ability  1 


Ability  2 


This  policy  typically  specifies  that: 

1 .  The  needed  skills  and  knowledge  for  each  software  acquisition  managerial  and  technical  role 
are  identified. 

2.  The  training  program  is  developed  to  build  the  skill  base  of  the  organization,  to  fill  the 
specific  needs  of  the  projects,  and  to  develop  the  skills  of  individuals. 

3.  Training  is  provided  fi-om  within  the  acquisition  organization  or  obtained  fi-om  outside  the 
acquisition  organization  when  appropriate. 

Some  examples  of  externa!  training  sources  include: 

end  user-provided  training, 

commercially  available  training  courses, 

academic  programs, 

professional  conferences,  and 

seminars. _ 


4.  Training  vehicles  for  imparting  skills  and  knowledge  are  identified,  approved,  and  managed. 

Some  examples  of  training  vehicles  include: 

classroom  training, 
computer-aided  instruction, 
guided  self-study. 

formal  apprenticeship  and  mentoring  programs,  and 
facilitated  videos. _ ^ _ 


Responsibility  for  implementing  the  organization’s  training  program  is 
designated. 

Ability  to  perform 


A  group  that  is  responsible  for  fulfilling  the  training  needs  of  the 
organization  exists. 

The  members  of  the  training  group  may  include  full-time  or  part-time  instructors  drawn 
from  the  organization  and  from  external  sources.  _ _ 


Adequate  resources  are  provided  for  training  program  activities. 

1 .  Resources  include: 

►  Funding. 

►  Staff. 
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Equipment. 

Tools. 
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Ability  4 


Activity  1 


2.  Appropriate  facilities  are  made  available  to  conduct  training. 

►  Classroom  training  facilities  should  be  separated  from  the  students'  work  environments 
to  niinimize  interruptions. 

►  Where  appropriate,  training  is  conducted  in  settings  that  closely  resemble  actual 
performance  conditions  and  includes  activities  to  simulate  actual  work  situations. 

Members  of  the  training  group  have  the  necessary  skills  and  knowledge  to 
perform  their  training  activities. 

Some  examples  of  ways  to  provide  these  skills  and  knowledge  include: 
training  in  instructional  techniques,  and 

refresher  training  in  the  subject  matter. _ 

Software  acquisition  management  personnel  receive  orientation  on  the 
training  program. 

Some  examples  of  topics  for  orientation  include: 

corporate  training  program  objectives  and  plan, 
process  for  determination  of  training  needs, 
methods  for  providing  required  training,  and 
identification  of  training  sources. _ 


Activities  performed 


The  organization’s  training  program  is  developed  and  maintained. 

Some  examples  of  training  program  elements  include: 

the  organization's  training  plan, 
training  materials, 

development  or  procurement  of  training, 
conduct  of  training, 
training  facilities, 
appraisal  of  training,  and 

maintaining  training  records. _ 


The  organization's  training  program  typically  covers: 

1 .  The  set  of  skills  needed  and  when  those  skills  are  needed. 

2.  Training  that  is  required,  for  whom  it  is  required,  and  when  it  is  required. 
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Level  3 :  The  Defined  Level 


Activity  2 


Activity  3 
Activity  4 


Activity  5 


Training  for  individuals  is  tied  to  their  woric  responsibilities  such  that  on-the-job  activities  or  outside 
experience  will  reinforce  the  training  within  a  reasonable  time  after  receiving  the  training. _ 


3 .  Developing  individual  training  plans. 

4.  How  training  will  be  provided. 


The  training  may  be  provided  by  the  project  by  the  organization’s  training  program,  or  by  an  external 


Each  software  acquisition  project  identifies  speciflc  training  needs  and 
develops  a  training  plan  in  accordance  with  training  program  procedures. 

The  project's  training  plan  typically  covers: 

1 .  The  set  of  skills  needed  and  when  those  skills  are  needed. 

2.  Skills  for  which  training  is  required  and  the  skills  that  will  be  obtained  via  other  vehicles. 

3.  Training  that  is  required,  for  whom  it  is  required,  and  when  it  is  required. 

Training  for  individuals  is  tied  to  their  work  responsibilities  such  that  on-the-job  activities  or  outside 
experience  will  reinforce  the  training  within  a  reasonable  time  after  receiving  the  training. _ 

4.  How  training  will  be  provided  with  a  breakdown  of  resources  required  to  provide  this 
training. 


The  training  may  be  provided  by  the  project  by  the  organization's  training  program,  or  by  an  external 
_ _ 

5.  The  requirement  that  the  software  acquisition  project's  training  plans  undergo  a  peer  review. 

Software  training  for  the  project  team  is  performed  in  accordance  with 
the  organization’s  training  program. 

A  waiver  procedure  for  required  training  is  established  and  used  to 
determine  whether  individuals  already  possess  the  knowledge  and  skills 
required  to  perform  their  designated  roles. 

Training  records  are  maintained. 

Some  of  the  records  to  be  maintained  are: 

1 .  All  students  who  successfully  complete  each  training  course  or  other  approved  training 
activity. 

2.  All  students  who  successfully  complete  their  designated  required  training  as  specified  in 
their  training  plan. 

3 .  Successfully  completed  training. 
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Training  Program 


Activity  6 


Measurement  1 


Verification  1 


Measurements  are  used  to  determine  the  quality  of  the  training  program. 


Some  examples  of  measurements  include: 

reviews  of  the  courses  from  the  students,  and 
feedback  from  the  software  managers. _ 


Measurement  and  analysis 


Measurements  are  made  and  used  to  determine  the  status  of  the  training 
program  activities  and  resultant  products. 


Some  examples  of  measurements  include: 

effort  expended; 
funds  expended; 

progress  towards  completion  of  training  program 
planning,  projects'  training  plans,  and  training  records; 
completion  of  milestones;  and 
cost  of  the  training  program. _ 


Verifying  implementation 


Training  program  activities  are  reviewed  by  organization  management  on 
a  periodic  basis. 


The  primary  purpose  of  these  reviews  by  organization  management  is  to  provide  awareness 
of,  and  insight  into,  training  program  activities  at  an  appropriate  level  of  abstraction  and 
in  a  timely  manner.  The  reviews  verify  that  organization  policy  is  being  implemented.  The 
time  between  reviews  should  satisfy  the  needs  of  the  organization  and  may  be  lengthy,  as 
long  as  adequate  mechanisms  for  exception  reporting  are  available. _ 
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Levels;  The  Defined  Level 
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Level  4  -  The  Quantitative  Level _ 

At  the  Quantitative  Level,  the  project  team  sets  quantitative  quality  objectives  for  processes, 
products,  and  services.  Measures  are  established  to  provide  a  quantitative  foundation  for 
evaluating  project  processes,  products,  and  services. 

Project  teams  achieve  control  over  acquisition  processes,  products,  and  services  by  narrowing  the 
variation  in  project  performance  to  within  acceptable  quantitative  boundaries.  Data  on  the 
defined  software  acquisition  process  and  variations  outside  the  acceptable  quantitative  boundaries 
are  used  to  adjust  the  process  to  prevent  recurrence  of  defects.  An  acquisition  organization-wide 
process  repository  is  used  to  collect  and  analyze  data  fi'om  the  projects'  defined  software 
acquisition  processes. 

The  process  capability  of  Level  4  acquisition  organizations  can  be  summarized  as  measured  and 
operating  within  measurable  limits.  This  level  of  process  capability  allows  an  organization  to 
predict  process  and  product  quality  trends  within  the  quantitative  bounds  of  these  limits.  When 
these  limits  are  exceeded,  action  is  taken  to  correct  the  situation. 

Level  4  key  process  areas  are; 

Quantitative  Process  Management 
Quantitative  Acquisition  Management 
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Level  4:  The  Quantitative  Level 


Quantitative  Process  Management _ 

a  key  process  area  for  Level  4:  Quantitative _ 

The  purpose  of  Quantitative  Process  Management  is  to  control  the  process  performance  of  the 
software  acquisition.  Projects  fiilly  implementing  quantitative  process  management  will  have 
stable  processes  that  are  under  quantitative  control. 

Quantitative  Process  Management  involves  each  project  team  setting  performance  objectives, 
measuring  performance,  analyzing  results,  and  making  adjustments  to  maintain  performance 
within  acceptable  limits.  Process  performance  variations  (i.e.,  variations  attributable  to  specific 
implementations  of  the  process)  are  measured  and  actions  taken  to  bring  the  process  performance 
within  acceptable  limits.  When  the  project  team's  process  performance  is  stabilized  within 
acceptable  limits,  the  defined  software  acquisition  process,  the  associated  measurements,  and  the 
acceptable  performance  limits  are  baselined  to  permit  quantitative  control  of  the  project  team's 
process  performance. 

The  acquisition  organization  collects  process  performance  data  fi’om  the  software  acquisition 
projects  and  uses  these  data  to  assess  the  capability  of  its  standard  software  acquisition  process 
(see  the  Process  Definition  and  Maintenance  key  process  area).  The  capability  of  the  acquisition 
organization's  standard  software  acquisition  process  is  indicative  of  the  performance  that  can  be 
expected  from  the  next  software  acquisition  project  it  undertakes.  These  capability  data  are,  in 
turn,  used  by  the  software  acquisition  project  teams  to  set  their  performance  objectives  and  to 
analyze  the  performance  of  their  defined  software  acquisition  processes.  The  capability  data  are 
also  used  by  the  project  teams  in  tailoring  the  acquisition  organization's  standard  software 
acquisition  process  to  a  particular  acquisition. 

Goals 


Goal  1  The  performance  of  each  project's  defined  software  acquisition  process  is 

quantitatively  controlled. 

Goal  2  The  performance  of  the  acquisition  organization's  standard  software 

acquisition  process  is  described  in  quantitative  terms. 
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Commitment  to  perform 


Commitment  1  The  acquisition  organization  has  a  written  policy  for  the  measurement 
and  quantitative  control  of  software  acquisition  process  performance. 

The  term  "quantitative  control"  implies  any  quantitative  or  statistically-based  technique 
appropriate  for  analyzing  a  software  acquisition  process,  identifying  causes  of  process 
performance  variations,  and  adjusting  the  process  to  bring  performance  within  prescribed 
limits. _ _ 

This  policy  typically  specifies  that: 

1 .  Each  project  team  plans  and  implements  quantitative  control  of  its  defined  software 
acquisition  process. 

2  Access  to  sensitive  data  is  appropriately  controlled. 

Commitment  2  The  acquisition  organization  has  a  written  policy  for  analysis  of  the 
capability  of  its  standard  software  acquisition  process. 

This  policy  typically  specifies  that: 

1  Each  project  team's  measurements  of  process  performance  are  analyzed  to  establish  and 

maintain  a  process  capability  baseline  for  the  acquisition  organization’s  standard  software 
acquisition  process. 

►  The  process  capability  baseline  includes: 

*  The  description  of  the  acquisition  organization's  standard  software  acquisition 
process. 

*  The  standard  definitions  of  the  measurements. 

*  The  expected  range  of  values  for  the  measurements. 

2.  The  acquisition  organization's  software  acquisition  process  capability  baseline  is  used  by 
each  project  team  in  establishing  its  process  performance  objectives. 

Ability  to  perform 


Ability  1  A  group  that  is  responsible  for  coordinating  quantitative  process 

management  activities  for  each  project  team  exists. 


Either  this  group  is  the  software  acquisition  process  group  or  its  activities  are  closely 
coordinated  with  that  group. _ _ _ 
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Level  4:  The  Quantitative  Level 


Ability  2 


Ability  3 
Ability  4 


Ability  5 


Adequate  resources  are  provided  for  quantitative  process  management 
activities. 

Resources  include; 

1.  Funding. 

2.  Staff. 

3.  Equipment. 

4.  Tools. 

►  Tools  to  support  quantitative  process  management  activities  are  made  available. 


Some  examples  of  quantitative  process  management  tools  include: 

project  management  systems, 
cost  and  schedule  control  systems, 
requirements  management  systems, 
database  systems, 

quantitative  analysis  packages,  and 

defect  tracking  packages. _ 


Acquisition  organization  management  support  exists  for  collecting, 
recording,  storing,  and  analyzing  process  and  product  measurement  data. 

The  individuals  implementing  or  supporting  quantitative  process 
management  activities  have  experience  or  receive  required  training. 


Experience  means,  for  example,  having  participated  in  a  software  acquisition  management 
role  on  at  least  one  project  and  having  a  minimum  of  three  years  acquisition  experience. 


Some  examples  of  experience  or  training  include: 

defining  and  performing  the  software  acquisition  process; 
modeling  and  analyzing  the  software  acquisition  process; 
selecting,  collecting,  and  verifying  process  measurement  data; 
applying  basic  quantitative  methods  and  analysis  techniques;  and 
defining  quantitative  objectives  for  process  management. _ 


Refer  to  the  Training  Program  key  py^ocess  area  for  a  desciiption  of  training  practices. 

The  members  of  the  project  team  and  groups  supporting  the  software 
acquisition  project  receive  orientation  on  the  objectives  and  values  of 
quantitative  process  management. 
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Activities  performed 


Quantitative  Process  Management 


Activity  1  The  acquisition  organization’s  software  acquisition  process  capability 

baseline  is  established  and  maintained  according  to  a  written  procedure. 

This  procedure  typically  specifies  that: 

1 .  The  project  team's  defined  software  acquisition  process  data  are  recorded  in  the  acquisition 
organization's  software  acquisition  process  repository. 

Refer  to  Activity  6  of  the  Process  Definition  and  Maintenance  key  process  area. 

2.  Each  project  team's  process  performance  baseline  is  incorporated,  as  appropriate,  into  the 
acquisition  organization's  process  capability  baseline. 

3.  The  process  capability  baseline  for  the  acquisition  organization's  standard  software 
acquisition  process  is  documented,  managed,  and  controlled. 

4.  Process  capability  trends  for  the  acquisition  organization's  standard  software  acquisition 
process  are  examined  to  predict  likely  defects  or  opportunities  for  improvements. 


Some  examples  of  using  capability  trends  include: 

predicting  the  occurrence  of  project  defects  and  comparing  the  predictions  to  actuals  and 
predicting  the  distribution  and  severity  of  defects  remaining  in  a  project  team  work  product  based  on  data 
from  reviews. _ _ _ _ _ 


Some  examples  of  areas  that  are  sources  of  defects  include: 

items  for  estimating  and  planning, 

requirements  definition, 

requirements  analysis, 

solicitation  package  preparation, 

reviews  of  major  contractor  developed  documents, 

items  and  activities  that  have  been  prone  to  defect  insertion  in  the  past, 

activities  for  implementing  changes  and  fixing  defects,  and 

labor-intensive  activities. _ 


Some  examples  of  areas  that  are  opportunities  for  improvement  include: 

activities  that  other  projects  and  organizations  have  successfiilly  automated; 
project  support  items  and  activities,  such  as  training  and  tools; 
quality-oriented  activities;  and 

labor-intensive  activities. _ 


5.  Changes  to  the  acquisition  organization's  standard  software  acquisition  process  are  tracked 
and  analyzed  to  determine  their  effect  on  the  process  capability  baseline. 

Activity  2  Each  project  team  performs  its  activities  in  accordance  with  its 

documented  quantitative  process  management  plans. 
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The  plans  typically  cover: 

1 .  The  goals  and  objectives  of  the  project  team's  quantitative  process  management  activities. 

2 .  The  software  acquisition  tasks  or  other  acquisition  tasks  that  will  be  measured  and  analyzed. 

The  data  collection  and  the  quantitative  analyses  strategy  are  based  on  the  project’s  defined  software 
acquisition  process. _ _ _ — 

3 .  The  instrumentation  of  the  project's  defined  software  acquisition  process. 

The  instnimentation  is  based  on  the  acquisition  organization's  measurement  program,  the  description  of  the 
acquisition  organization's  standard  software  acquisition  process,  and  the  description  of  the  project's  defined 
so^are  acquisition  process. _ _ _ ^ _ 

4.  The  quantitative  process  management  activities  to  be  performed  and  the  schedule  for  these 
activities. 

!  In  addition  to  current  organizational  and  project  needs,  measurements  that  may  be  useful  to  future  efforts 
!  may  be  included. _ _ _ — _ I 

5.  The  groups  and  individuals  responsible  for  the  quantitative  process  management  activities. 

6  The  resources  required  to  perform  the  quantitative  process  management  activities,  including 
staff  and  tools. 

7.  The  procedures  to  be  followed  in  performing  the  quantitative  process  management  activities. 

Activity  3  The  measurement  data  used  to  quantitatively  control  the  project’s 

defined  software  acquisition  process  are  collected  in  accordance  with  the 
project’s  quantitative  process  management  plans. 


Some  examples  of  measurement  data  include: 

! 

project  softw'are  size,  efibrt,  schedule,  and  cost  estimates  used  in  the  solicitation  phase; 
actual  project  data  on  software  size,  effort,  schedule,  and  cost; 
project  team  productivity  data  (e.g.,  staff  hours  expended,  document  pages  reviewed,  and 
requirements  normally  tested); 

project  team  quality  measurements  (e.g.,  number  and  severity  of  defects  found  in  the 
project  requirements  and  project  team  work  products);  and 
timeliness  of  project  team  work  products. _ 


Project  team  work  products  are  those  products  that  are  produced  by  the  project  team  as  it  execirtes  the 
project's  defined  software  acquisition  process  (e.g.,  solicitation,  acquisition  plans,  document  reviews). 
Project  team  woric  products  are  not  the  deliverables,  products,  end  items,  or  other  output  produced  by 
;the  contractor  in  satisfaction  of  the  contract. _ _ _ 


The  plans  topically  specify  that: 

1 .  The  measurement  data  collected  support  the  acquisition  organization's  and  the  project  team's 
measurement  objectives. 
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2.  The  specific  measurement  data  to  be  collected,  their  precise  definitions,  the  intended  use  and 
analysis  of  each  measurement,  and  the  process  control  points  at  which  they  are  collected  are 
defined. 

These  data  would  normally  be  combined  to  develop  productivity  measures  for  insight  into  process 
perfoimance.  For  example,  the  number  of  defects  found  in  an  inspection,  along  with  the  size  of  and  effort 
involved  in  the  inspection,  provides  a  means  of  measuring  the  productivity  of  the  inspection  (defects  per 
size/effort).  This  measure  can  then  be  compared  across  the  project  to  determine  the  relative  effectiveness 
of  tlie  inspection  process  as  well  as  the  product.  Naturally,  a  judgement  is  necessary  to  preclude  a  singular 
characteristic,  such  as  an  unusually  low  number  of  defects  for  the  product,  from  skewing  the  r^lt.  When 
these  measures  are  applied  across  many  products  and  processes,  they  can  provide  useful  insight  into  process 
performance. _ _ _ _ _ _ _ 

3 .  The  measurements  cover  the  properties  of  the  key  software  acquisition  process  activities  and 
major  software  acquisition  work  products. 

4.  The  measurement  data  that  relate  to  the  acquisition  organization's  standard  software 
acquisition  process  are  collected  according  to  a  uniform  process  across  the  software 
acquisition  projects. 

5.  The  verification  of  each  project's  measurement  data  is  independently  determined. 

6.  The  collected  measurement  data  are  stored  in  the  acquisition  organization's  software 
acquisition  process  repository  as  appropriate. 

Refer  to  Activity  6  of  the  Process  Definition  and  Maintenance  key^  process  area. 

Activity  4  Each  project’s  defined  software  acquisition  process  is  analyzed  and 

quantitatively  controlled  according  to  the  project’s  quantitative  process 
management  plans. 

The  plans  typically  specify  that: 

1 .  Specific  data  analysis  activities  are  predefined. 

Some  examples  of  items  analyzed  include: 

input  data  required, 
tools  used, 

data  manipulations  performed, 
information  to  be  derived, 

decision  criteria  used  in  performing  the  analysis,  and 

criteria  for  deciding  what  actions  to  take  as  a  result  of  the  analysis. _ 

2.  Measurement  data  on  the  process  activities  throughout  the  project's  defined  software 
acquisition  process  are  identified,  collected,  and  analyzed. 

3 .  The  acceptable  limits  for  each  measurement  are  defined. 


An  example  of  establishu^  acceptable  limits  is  to  calculate  the  historical  standard  deviation  from  the  mean 
performance  of  the  process.  _ _ _ _ 


4.  The  actual  values  of  each  measurement  are  compared  to  the  acceptable  limits. 
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5.  Adjustments  are  made  to  bring  process  performance  in  line  with  the  established  acceptable 
limits. 

6.  Each  project  team’s  software  acquisition  process  performance  baseline  is  established  for  the: 

►  Definition  of  the  measurements. 

►  Actual  measurement  data. 

►  Acceptable  limits  for  the  measurements. 

7.  The  process  performance  baselines  for  the  software  acquisition  project  team  are  managed 
and  controlled. 

Activity  5  Reports  documenting  the  results  of  the  project  team's  quantitative 

process  management  activities  are  prepared  and  distributed. 

Activity  6  Causal  analysis  of  each  project’s  defined  software  acquisition  process  is 

conducted  on  a  periodic  basis  to  determine  root  causes  of  variances  from 
the  project's  plans. 

An  example  of  a  method  to  determine  root  causes  is  cause/effect  analysis. 

Activity  7  Changes  are  implemented  to  correct  the  project's  defined  software 

acquisition  process  where  it  is  out  of  expected  or  acceptable  bounds. 

Measurement  and  analysis 


Measurement  1  Measurements  are  made  and  used  to  determine  the  status  of  the 

quantitative  process  management  activities  and  resultant  products. 

Some  examples  of  measurements  include: 

effort  expended, 
funds  expended, 

progress  towards  completion  of  quantitative  process  management . 
planning  and  the  collection  of  measurement  data,  and 
completion  of  milestones. _ 


Measurement  2  Measurements  are  made  and  used  to  determine  the  effectiveness  of  the 
quantitative  process  management  activities  and  resultant  products. 

Some  examples  of  measurements  include: 

the  percentage  of  integration  of  the  quantitative  process  management  activities  into  the 
acquisition  organization’s  standard  software  acquisition  process,  and 
the  percentage  of  integration  of  the  quantitative  process  management  activities  into  the 
project’s  defined  software  acquisition  process. _ 
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Verifying  implementation 


Verification  1  Quantitative  process  management  activities  are  reviewed  by  acquisition 
organization  management  on  a  periodic  basis. 

The  primary  purpose  of  these  reviews  by  acquisition  organization  management  is  to 
provide  awareness  of,  and  insight  into,  quantitative  process  management  activities  at  an 
appropriate  level  of  abstraction  and  in  a  timely  manner.  The  reviews  verify-  that  acquisition 
organization  policy  is  being  implemented.  The  time  between  reviews  should  satisfy  the 
needs  of  the  organization  and  may  be  lengthy,  as  long  as  adequate  mechanisms  for 
exception  reporting  are  available.  _ _ _ 

Verification  2  Each  project  team’s  quantitative  process  management  activities  are 
reviewed  by  the  project  manager  on  both  a  periodic  and  event-driven 
basis. 

This  review  may  be  conducted  in  conjunction  with  project  management  oversight  reviews, 
such  as  those  conducted  for  the  Project  Performance  Management  and  Contract 
Performance  Management  key  process  areas. _ _ _ 
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Quantitative  Acquisition  Management _ 

a  key  process  area  for  Level  4:  Quantitative _ 

The  purpose  of  Quantitative  Acquisition  Management  is  to  manage  the  contractual  effort  through 
the  application  of  quantitative  methods. 

Quantitative  Acquisition  Management  involves  utilizing  process  and  product  measurements  as  an 
intrinsic  part  of  management  review  and  oversight  to  quantitatively  manage  the  acquisition  of 
software  products  and  services. 

As  the  acquisition  organization  continues  to  attain  higher  levels  of  maturity  there  is  a  transition  to 
quantitative  methods.  This  transition  is  marked  by  the  involvement  of  all  levels  of  acquisition 
management.  The  result  represents  an  advance  from  contract  performance  management  to 
acquisition  management  using  quantitative  methods.  Another  result  of  this  transition  is  an 
expected  increase  in  the  quality  of  acquired  products  and  services. 

The  quantitative  acquisition  management  process  is  integrated  with  quantitative  process 
management.  The  actions  of  quantitative  process  management  at  the  project  level  and  across  the 
acquisition  organization  are  integral  to  acquisition  management. 

Goals 


Goal  1  Quantitative  objectives  for  the  acquired  products  and  services  are 

defined. 

Goal  2  The  contracted  effort  is  managed  quantitatively. 

Commitment  to  perform 


Commitment  1  The  acquisition  organization  has  a  written  policy  for  quantitatively 
managing  the  acquisition  of  software  products  and  services. 

The  tenn  "quantitative  management"  implies  using  quantitative  or  statistical  based 
techniques  for  analyzing  the  acquired  products  and  services,  identifying  causes  of 
performance  variations,  and  making  adjustments  to  bring  the  products  and  services  within 
prescribed  limits. _ _ _ 
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This  policy  typically  specifies  that: 

1 .  Each  project’s  defined  software  acquisition  process  calls  for  planning  and  implementing 
quantitative  control  of  its  software  acquisition. 

2.  Each  project  defines  quantitative  objectives  for  the  acquisition  of  software  products  and 
services  and  collects  measurements  based  on  the  project's  defined  software  acquisition 
process. 

Commitment  2  The  acquisition  organization  has  a  written  policy  that  incorporates 

quantitative  methods  into  management  review  and  oversight  activities. 

Ability  to  perform 


Ability  1  Project  team  personnel  have  experience  and  are  trained  in  quantitative 

methods. 


Experience  means,  for  example,  having  participated  in  an  acquisition  where  quantitative 
methods  have  been  applied  to  the  process,  products,  and  services  of  the  acquisition. 

Ability  2  The  members  of  the  project  team  and  groups  supporting  the  software 

acquisition  project  receive  orientation  on  the  goals  and  values  of 
quantitative  methods. 

Activities  performed 


Activity  1  Each  project  team  performs  its  activities  in  accordance  with  its 

documented  quantitative  acquisition  management  plans. 

These  plans  typically  cover: 

1 .  Quantitative  objectives  for  acquired  products  and  services. 

2.  Management  practices  to  be  integrated  with  quantitative  methods. 

Some  examples  of  management  practices  include: 

risk  management 
configuration  management 
evaluation,  and 

requirements  development  and  management. 

3 .  Methods  for  the  collection  of  data  for  the  measurement  of  acquired  products  and  services. 

4.  Analysis  of  data  to  determine  deviations  from  stated  objectives. 


CMU/SEI-96-TR-020 


L4-11 


Quantitative  Acquisition  Management 


Level  4:  The  Quantitative  Level 


Activity  2 


Activity  3 


Activity  4 


5.  The  resources  required  to  perform  collection  and  analysis  of  quantitative  measures. 

6.  The  quality  attributes  expected  in  acquired  products  and  services. 


Some  examples  of  software  quality  attributes  are; 

functionality, 
reliability, 
reusability, 
maintainability,  and 

usability.  _ 


The  acquisition  organization  utilizes  quantitative  measures  as  a  normal 
part  of  management  review  and  oversight  of  acquired  products  and 
services. 

Some  of  the  project  management  areas  that  are  tracked  using  quantitative  process  and  product 
measures  are: 

1.  Risk  management. 

2.  Solicitation. 

3.  Evaluation. 

4.  Requirements  development  and  management. 

The  quantitative  objectives  for  each  project’s  software  products  and 
services  are  defined. 

1 .  Attributes  are  identified  that  indicate  how  well  the  software  products  will  perform  or  how 
well  they  will  be  engineered  and  maintained. 

2.  Measurable  values  (required  and  desired)  are  defined  for  each  attribute. 

3 .  The  methods  to  measure  the  attributes  are  identified. 

Some  examples  of  methods  to  measure  the  attributes  typically  include: 
conducting  tests  and 

formal  inspections. _ 


The  quantitative  objectives  for  each  project's  products  and  services  are 
incorporated  into  the  solicitation  package  and  resulting  contract 
according  to  the  project's  deflned  software  acquisition  process. 

The  process  typieally  includes  contract  mechanisms  that  provide  the  project  team  sufheient 
data  to  allow  measurement  and  analysis  of  software  products  and  services. _ 
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Quantitative  Acquisition  Management 


Activity  5 


Activity  6 


Activity  7 


Each  project's  acquired  software  products  and  services  are  measured, 
analyzed,  and  compared  to  the  project's  established  quantitative 
objectives. 

Acquisition  management  uses  the  results  of  these  actions  to  take  corrective  actions  to  the 
project’s  defined  software  acquisition  process  in  order  to  ensure  that  the  project's  products 
and  services  are  acquired  in  accordance  with  established  obiectives. _ 

Refer  to  Activities  3  and  4  of  the  Quantitative  Process  Management  key  process  area. 

Causal  analysis  of  each  project's  acquired  products  and  services  is 
conducted  on  a  periodic  basis  to  determine  root  causes  of  variances  from 
the  project's  plans. 


An  example  of  a  method  to  determine  root  causes  is  cause/efFect  analysis. 


Changes  are  implemented  to  correct  project  acquired  products  and 
services  that  are  out  of  expected  or  acceptable  bounds. 

Measurement  and  analysis 


Measurement  1  Measurements  are  made  and  used  to  determine  the  status  of  the 

quantitative  acquisition  management  activities  and  resultant  products. 

Some  examples  of  measurements  include: 

effort  expended, 
funds  expended, 

progress  towards  completion  of  quantitative  acquisition  management 
planning  and  the  quantitative  objectives  for  the  solicitation  and  contract,  and 

completion  of  milestones. _ _ _ 

Measurement  2  Measurements  are  made  and  used  to  determine  the  effectiveness  of  the 
quantitative  acquisition  management  activities  and  resultant  products. 

Some  examples  of  measurements  include: 

analytical  reports  that  address  quality  of  software  products  and  services, 
percentages  of  variances  from  stated  objectives  (i.e.,  based  on  upper  and 
lower  bounds),  and 

percentages  of  variances  from  quantitative  objectives. _ 
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Verification  1 


Verification  2 


Verifying  implementation 


Quantitative  acquisition  management  activities  are  reviewed  by 
acquisition  organization  management  on  a  periodic  basis. 


The  primary  purpose  of  these  reviews  by  acquisition  organization  management  is  to 
provide  awareness  of,  and  insight  into,  quantitative  acquisition  management  activities  at 
an  appropriate  level  of  abstraction  and  in  a  timely  manner.  The  reviews  verify  that 
acquisition  organization  policy  is  being  implemented.  The  time  between  reviews  should 
satisfy  the  needs  of  the  organization  and  may  be  lengthy,  as  long  as  adequate  mechanisms 
for  exception  reporting  are  available. _ _ _ 


Quantitative  acquisition  management  activities  are  reviewed  by  the 
project  manager  on  both  a  periodic  and  event-driven  basis. 


L4-14 


CMU/SEI-96-TR-020 


Level  5  -  The  Optimizing  Level _ 

At  the  Optimizing  Level,  the  acquisition  organization  is  focused  on  continuous  process 
improvement.  An  acquisition  organization  has  the  means  to  identify  processes  that  are  candidates 
for  optimization.  Statistical  evidence  is  available  to  analyze  process  effectiveness  and  is  used  to 
refine  policies.  Technological  innovations  that  exploit  the  best  software  acquisition  management 
and  engineering  practices  are  identified,  appraised,  and  institutionalized. 

Level  5  acquisition  organizations  are  continuously  striving  to  reduce  variation  in  performance 
while  increasing  their  level  of  performance.  Improvement  occurs  both  by  incremental 
advancements  in  the  existing  mechanisms  and  by  innovations  using  new  technologies  and 
techniques. 

Level  5  key  process  areas  are: 

Continuous  Process  Improvement 
Acquisition  Innovation  Management 


1 
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Level  5:  The  Optimizing  Level 

Continuous  Process  Improvement _ 

a  key  process  area  for  Level  5:  Optimizing _ 

The  purpose  of  Continuous  Process  Improvement  is  to  evolve  the  software  acquisition  processes 
used  in  the  acquisition  organization  through  managed  continuous  process  improvement. 
Quantitative  objectives  for  the  acquisition  organization's  standard  software  acquisition  process 
and  the  projects'  defined  software  acquisition  processes  are  the  targets  of  the  improvement 
activity. 

Continuous  Process  Improvement  involves  defining  quantitative  process  improvement  objectives 
with  the  involvement  and  sponsorship  of  acquisition  organization  management.  It  is  a  continuous 
effort  to  proactively  and  systematically  identify,  appraise,  and  implement  improvements  to  the 
acquisition  organization's  standard  software  acquisition  process  and  the  projects'  defined  software 
acquisition  processes. 

The  commitment  to  continuous  process  improvement  is  acquisition  organization-wide.  Training 
and  incentive  programs  are  established  to  encourage  and  enable  all  acquisition  organization 
personnel  to  participate  in  the  software  acquisition  continuous  process  improvement  activities. 
Improvement  opportunities  are  identified  and  appraised  in  terms  of  how  well  they  move  the 
acquisition  organization  and  its  projects  toward  software  acquisition  continuous  process 
improvement  objectives. 

When  software  acquisition  process  improvements  are  approved  for  normal  practice,  the 
acquisition  organization's  standard  software  acquisition  process  and  the  projects'  defined  software 
acquisition  processes  are  revised.  The  Process  Definition  and  Maintenance  key  process  area 
defines  the  actions  for  changing  the  acquisition  organization's  standard  software  acquisition 
process.  The  Project  Performance  Management  key  process  area  defines  the  actions  for  changing 
the  projects'  defined  software  acquisition  processes. 

The  Acquisition  Innovation  Management  key  process  area  defines  the  actions  for  adopting  and 
transforming  new  techniques  and  technologies  into  the  acquisition  organization. 

Goals 


Goal  1  Participation  in  continuous  process  improvement  activities  is  acquisition 

organization-wide. 

Goal  2  The  acquisition  organization's  standard  software  acquisition  process  and 

the  projects'  defined  software  acquisition  processes  are  improved 
continuously. 
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Commitment  to  perform 


Commitment  1  The  acquisition  organization  has  a  written  policy  for  the  implementation 
of  software  acquisition  process  improvements. 

This  policy  typically  specifies  that: 

1 .  The  acquisition  organization  has  quantitative  objectives  for  improving  the  process 
effectiveness  of  its  standard  software  acquisition  process  and  the  projects'  defined  software 
acquisition  processes. 

2.  The  acquisition  organization’s  software  acquisition  process  improvement  activities  are 
directed  toward  improving  the  quality  of  project  team  products  and  services  and  increasing 
project  team  productivity. 

3.  All  of  the  acquisition  organization's  personnel  are  expected  to  participate  in  improving  the 
software  acquisition  processes. 

Commitment  2  Acquisition  organization  management  actively  sponsors  process 
improvement  activities. 

Acquisition  organization  management: 

1 .  Establishes  the  organization's  strategic  objectives  and  plans  for  process  improvement. 

2.  Allocates  resources  for  process  improvement  activities. 

3 .  Reviews  the  project  managers'  process  improvement  objectives  and  their  process 
improvement  plans. 

4.  Reviews  and  approves  the  process  improvement  plans. 

5.  Tracks  performance  of  the  continuous  process  improvement  activities  against  their  defined 
objectives. 

6.  Maintains  a  consistent  priority  focus  on  process  improvement  in  the  face  of  project  crises. 

7.  Ensures  that  process  improvement  issues  are  resolved  promptly. 

8.  Rewards  participation  in  the  process  improvement  activities. 

Ability  to  perform 


Ability  1  Adequate  resources  are  provided  for  continuous  process  improvement 

activities. 
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Ability  2 


Activity  1 


Level  5:  The  Optimizing  Level 


Resources  include: 

1.  Funding. 

2.  Staff. 


Experienced  individuals  who  have  expertise  in  defining  and  analyzing  software  acquisition  processes  are 
made  available  to  help  the  acquisition  organization  in  its  process  improvement  activities. _ 


3.  Equipment. 

4.  Tools. 

Acquisition  organization  personnel  receive  required  training  in 
continuous  process  improvement. 

!  Some  examples  of  training  for  software  acquisition  management  personnel  include: 

managing  technological  and  organizational  change, 
j  team  building,  and 

^  teamwork  skills  as  applied  to  continuous  process  improvement. _ 

Some  examples  of  training  for  project  personnel  include: 
the  principles  of  quality  and  process  improvement,  and 

the  procedures  for  proposing  process  improvement. _ _ 

Some  examples  of  training  for  acquisition  organization  management  personnel  include: 

the  principles  of  process  improvement, 
setting  and  tracking  objectives  for  process  improvement,  and 
:  motivation  and  team  building  in  a  continuous  process  improvement  environment. 


Refer  to  the  framing  Program  key  process  area  for  a  description  of  training  practices. 

Activities  performed 


The  acquisition  organization  performs  its  activities  in  accordance  with  its 
documented  continuous  process  improvement  plans. 

The  plans  typically: 

1 .  Identify  the  resources  required. 

2.  Present  the  quantitative  short-term  and  long-term  objectives  for  software  acquisition  process 
performance  and  improvement. 
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3 .  Specify  the  procedures  for: 

►  The  acquisition  organization  managers  overseeing  the  process  improvement  activities. 

►  The  software  acquisition  managers  planning  and  coordinating  process  improvement 
activities. 

►  Individuals  and  project  teams  identifying,  appraising,  implementing,  and  evaluating 
software  acquisition  process  improvements. 

►  The  teams  developing  process  improvements  for  assigned  software  acquisition  process 
areas. 

4.  Specify  the  administrative  and  support  procedures  required  to  maintain  process 
improvement. 

►  Administrative  procedures  to  encourage  participation  in  and  facilitate  the  process 
improvement  activities  are  included, 

►  Procedures  for  the  oversight  and  review  of  the  process  improvement  activities  by 
administrative  personnel  are  included. 

►  Procedures  for  the  recognition  of  the  roles  and  contribution  of  personnel  to  process 
improvement  are  included. 

5.  Are  reviewed  and  approved  by  acquisition  organization  management. 

6.  Are  managed  and  controlled. 

Activity  2  The  software  acquisition  process  group  coordinates  process  improvement 

activities. 

The  software  acquisition  process  group: 

1 .  Coordinates  the  definition  of  quantitative  objectives  for  software  acquisition  process 
performance  and  improvement  and  reviews  the  objectives  with  acquisition  organization 
management  for  its  endorsement. 

2.  Defines  the  measurement  plans  for  software  acquisition  process  performance. 

3 .  Participates  in  the  effort  to  define  the  acquisition  organization's  training  needs  for  process 
improvement  and  supports  the  development  and  presentation  of  training  course  materials. 

Refer  to  the  Training  Program  key  pivcess  area  for  a  description  of  training  practices. 

4.  Defines  and  maintains  the  procedures  for  handling  process  improvement  proposals. 

5.  Reviews  process  improvement  proposals  and  coordinates  actions  for  these  proposals. 

6.  Tracks  status,  accomplishments,  and  participation  in  the  process  improvement  activities  and 
periodically  reports  the  results  to  acquisition  organization  management. 
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7.  Reviews,  approves,  manages,  and  controls  any  changes  to  the  acquisition  organization's 
standard  software  acquisition  process. 

8.  Defines,  establishes,  and  maintains  the  process  improvement  records. 

Refer  to  the  Process  Defmition  and  Maintenance  key  process  area  for  an  introduction  to  the 
software  acquisition  process  group  and  the  acquisition  organization's  standard  software 
acquisition  prvcess. 

Activity  3  Process  improvement  proposals  are  handled  according  to  a  written 

procedure. 

This  procedure  typically  specifies  that: 

1 .  Process  improvement  proposals  are  submitted. 

The  process  iirqjrovement  proposals  may  be  submitted  at  any  time,  by  any  member  of  the  organization,  and 
may  address  any  of  the  software  acquisition  processes  or  the  area  of  process  improvement. _ 

2.  Each  process  improvement  proposal  is  evaluated,  the  expected  benefits  are  determined,  a 
decision  is  made  whether  to  implement  the  proposal,  and  the  decision  rationale  is 
documented. 

3.  Implementation  of  the  approved  process  improvement  actions  is  assigned  and  planned. 

4.  The  status  of  each  process  improvement  proposal  is  tracked. 

5.  Completed  process  improvement  actions  are  reviewed,  verified,  and  approved  before 
closure. 

6.  Submitters  of  process  improvement  proposals  receive: 

►  Prompt  acknowledgment  of  their  proposals. 

►  Notification  of  the  disposition  of  their  proposals. 

Activity  4  Process  improvements  are  transferred  into  practice  according  to  a  written 

procedure. 

This  procedure  typically  specifies  that: 

1 .  Appropriate  process  changes  are  incorporated  into  the  acquisition  organization's  standard 
software  acquisition  process. 

Refer  to  Activities  2,  5,  and  4  of  the  Process  Defmition  and  Maintenance  key  process  area. 

2.  Appropriate  changes  are  incorporated  into  the  projects'  defined  software  acquisition 
processes. 

Refer  to  Activity  4  of  the  Project  Performance  Management  key  process  area. 
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Continuous  Process  Improvement 

Activity  5  Records  of  process  improvement  activities  are  maintained  in  the 

acquisition  organization's  repository  for  software  acquisition  process 
information. 

1 .  Information  about  the  initiation,  status,  and  implementation  of  the  process  improvement 
proposals  is  maintained. 

2.  Historical  data  are  maintained  and  reports  produced  on  process  improvement  activities  and 
results. 


Some  examples  of  records  and  reports  include  the: 

projects'  productivity*,  quality,  and  schedule  performances: 
projects’  defect  histories; 

organizational  quality  and  productivity  trends;  and 

cost,  schedule,  and  productivity  of  software  acquisition  process  definition  and  maintenance. 


Refer  to  Activity  6  of  the  Process  Definition  and  Maintenance  key  process  area. 

Measurement  and  analysis 


Measurement  1  Measurements  are  made  and  used  to  determine  the  status  of  the 
continuous  process  improvement  activities  and  resultant  products. 


Some  examples  of  measurements  include: 

effort  expended; 
funds  expended; 

progress  towards  completion  of  process  improvement  planning,  process  improvement 
records,  and  updates  to  the  software  acquisition  process  repositoiy;  and 
completion  of  milestones. _ _ _ 


Measurement  2  Measurements  are  made  and  used  to  determine  the  effectiveness  of  the 
continuous  process  improvement  activities  and  resultant  products. 

Some  examples  of  measurements  include: 

the  percentage  of  integration  of  process  improvement  activities  into  the  acquisition 
organization's  standard  software  acquisition  process, 

the  number  of  process  improvement  proposals  submitted  and  implemented  for  each 
process  area, 

the  response  time  for  handling  process  improvement  proposals, 

the  number  and  type  of  recognition  for  process  improvement  activities  awarded,  and 

analytical  reports  that  address  the  improvement  of  product  and  service  quality. _ 
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Verifying  implementation 


Veriflcation  1  Continuous  process  improvement  activities  are  reviewed  by  acquisition 
organization  management  on  a  periodic  basis. 

The  primary  purpose  of  these  reviews  by  acquisition  organization  management  is  to 
provide  awareness  of,  and  insight  into,  continuous  process  improvement  activities  at  an 
appropriate  level  of  abstraction  and  in  a  timely  manner.  The  reviews  verify  that  acquisition 
organization  policy  is  being  implemented.  The  time  between  reviews  should  satisfy  the 
needs  of  the  organization  and  may  be  lengthy,  as  long  as  adequate  mechanisms  for 
exception  reporting  are  available. _ _ _ 


Some  examples  of  review  subjects  include: 

participation  in  the  continuous  process  improvement  activities, 
process  perfomance, 
needed  changes  in  objectives, 
issues,  and 

revisions  to  the  continuous  process  improvement  plans  as  appropriate. _ 

Verification  2  Acquisition  organization  managers  and  project  managers  receive 

feedback  on  the  status  and  results  of  continuous  process  improvement 
activities. 

Feedback  is  provided  on  a  periodic  or  event-driven  basis  and  includes: 

1 .  A  summary  of  the  major  continuous  process  improvement  activities. 

2.  Significant  innovations  and  actions  taken  to  address  continuous  process  improvement. 

3.  A  summary  status  of  process  improvement  proposals  that  are  submitted,  opened,  and 
completed  or  closed. 

4.  Reports  on  the  effectiveness  of  implemented  process  improvements. 
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Acquisition  Innovation  Management _ 

a  key  process  area  for  Level  5:  Optimizing _ _ 

The  purpose  of  Acquisition  Innovation  Management  is  to  continually  improve  the  acquisition 
process  through  the  adoption  and  transfer  of  new  techniques  and  technologies.  Acquisition 
innovation  management  is  a  primary  responsibility  of  the  acquisition  organization;  however,  the 
adoption  activity  is  carried  out  through  individual  acquisition  projects.  While  the  project  can  act 
by  itself,  the  environment  for  adoption  should  be  fostered  and  led  by  the  acquisition  organization. 

Acquisition  Innovation  Management  involves  the  identification,  appraisal,  implementation, 
adoption,  and  transfer  of  new  techniques  and  technologies  that  support  the  software  acquisition 
process.  Techniques  and  technologies  include  methodologies,  tools,  and  practices. 

The  focus  is  on  improving  the  acquisition  process  through  the  adoption  and  implementation  of 
new  techniques  and  technologies.  Adoption  of  new  techniques  and  technologies  is  accomplished 
in  concert  with  continuous  process  improvement  (refer  to  the  Continuous  Process  Improvement 
key  process  area). 

Acquisition  innovation  management  of  new  techniques  and  technologies  encompasses  a  range  of 
possibilities.  These  techniques  and  technologies  are  those  which  are  new  on  the  horizon  or  are 
new  to  the  acquisition  organization  and  have  promise  of  providing  a  better  and  advanced 
acquisition  process.  They  may  range  from  introduction  of  a  new  technique  to  the  project  (such  as 
automated  documentation)  to  adoption  of  a  new  management  strategy  (e.g.,  product  line)  at  the 
acquisition  organization  level.  The  acquisition  organization  and  the  project  act  in  cooperation  to 
implement  new  techniques  and  technologies  that  may  provide  a  specific  benefit  to  the  project,  as 
well  as  an  overall  benefit  to  the  organization. 

Goals 


Goal  1  The  acquisition  organization  improves  the  software  acquisition  process 

through  the  adoption  and  implementation  of  new  techniques  and 
technologies  in  a  proactive,  normative  manner. 

Goal  2  Participation  in  the  acquisition  innovation  management  process  is 

organization-wide. 
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Commitment  1 


Commitment  2 

Ability  1 
Ability  2 


Ability  3 


Commitment  to  perform 


The  acquisition  organization  has  a  written  policy  for  acquisition 
innovation  management  activities. 

This  policy  typically  specifies  that: 

1 .  New  techniques  and  technologies  for  possible  implementation  in  the  acquisition 
organization’s  standard  software  acquisition  process  are  continually  appraised. 

2.  New  techniques  and  technologies  to  detennine  their  value,  cost,  risk,  and  benefit  to  the 
acquisition  process  are  appraised. 

3.  Implementation  of  new  techniques  and  technologies  is  managed  and  controlled. 

Acquisition  organization  management  sponsors,  actively  supports,  and 
provides  leadership  for  acquisition  innovation  management. 

Ability  to  perform 


A  group  that  is  responsible  for  performing  and  coordinating  acquisition 
innovation  management  activities  for  the  acquisition  organization  exists. 

Adequate  resources  are  provided  for  acquisition  innovation  management 
activities. 

Resources  include: 

1.  Funding. 

2.  Staff. 

3.  Equipment. 

4.  Tools. 

Individuals  performing  acquisition  innovation  management  activities 
have  experience. 


Experience  means,  for  example,  having  had  multiple  acquisition  management  roles  on 
several  projects,  understanding  the  application  of  techniques  and  technologies  in  the 
acquisition  process,  and  understanding  the  objectives  of  the  acquisition  organization. 
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Activity  1 


Activity  2 


Activity  3 


Activities  performed 


The  acquisition  organization  performs  its  activities  in  accordance  with  its 
documented  acquisition  innovation  management  plans. 

The  plans  typically  cover: 

1 .  The  appraisal  of  new  techniques  and  technologies  to  determine  their  applicability  and 
appropriateness  for  the  acquisition  organization. 

Some  examples  of  new  techniques  and  technologies  include: 

the  use  of  a  new  documentation  scheme. 

the  employment  of  formal  methods, 

the  employment  of  new  acquisition  paradigms, 

the  employment  of  asset  management  (reusable  components), 

the  implementation  of  software  architecture  managed  development,  and 

the  use  of  product  line  implementation  and  management. _ 

2.  The  resources  required. 

3 .  Assignment  of  re^onsibilities. 

4.  Review  and  appraisal  of  the  acquisition  innovation  management  activities. 

5.  The  detailing  of  specific  implementation  and  evaluation  practices  and  procedures. 

6.  Preparation  of  process  improvement  proposals. 

Refer  to  Activities  I  and  3  of  the  Continuous  Process  Improvement  key  process  area. 

The  group  responsible  for  conducting  acquisition  innovation 
management  activities  conducts  routine  and  periodic  appraisals  of  new 
techniques  and  technologies  as  candidates  for  inclusion  in  the  acquisition 
organization's  standard  software  acquisition  process. 


New  approaches  and  technologies  are  appraised  to  determine  their  effect  on  quality  and 
productivity  and  results  are  reported  to  acquisition  organization  management. _ 


Refer  to  Activities  2  and  5  of  the  Continuous  Process  Improvement  key  process  area. 

The  project  team  performs  its  activities  in  accordance  with  its 
documented  acquisition  innovation  management  plans. 
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The  plans  typically  cover: 

1 .  Management  of  the  implementation  process  for  the  inclusion  of  the  new  technique  or 
technology. 

2.  Implementation  process  of  the  adopted  technique  or  technology. 

3.  Evaluation  of  the  effect  of  the  implemented  technique  or  technology. 

4.  Resources  needed  to  manage  the  implementation  of  the  activity. 

Activity  4  The  acquisition  organization  works  with  the  projects  to  foster  an 

environment  which  facilitates  adoption  of  initiatives  beneficial  to  the 
acquisition  organization. 

Activity  5  Software  acquisition  management  personnel  are  kept  informed  of  new 

technologies. 

1 .  Information  on  new  techniques  and  technologies  is  made  available. 

2.  Information  on  techniques  and  technologies  already  in  use  within  the  acquisition 
organization  is  disseminated. 

3.  Information  on  the  status  of  new  techniques  and  technologies  being  implemented  within  the 
acquisition  organization  is  disseminated. 

Measurement  and  analysis 


Measurement  1  Measurements  are  made  and  used  to  determine  the  status  of  the 

acquisition  innovation  management  activities  and  resultant  products. 

Some  examples  of  measurements  include: 

effort  expended, 
funds  expended, 

progress  towards  completion  of  acquisition  mnovation  management  unprovement 
planning  and  appraisals  of  new  candidate  techniques  and  technologies,  and 
completion  of  milestones. _ _ 


Measurement  2  Measurements  are  made  and  used  to  determine  the  effectiveness  of  the 
acquisition  innovation  management  activities  and  resultant  products. 
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Some  examples  of  measurements  include: 

the  percentage  of  adoption  and  implementation  of  new  techniques  and  technologies  in 
the  project’s  defined  software  acquisition  process;  and 

analytical  reports  that  address  identification,  appraisal,  implementation,  and  adoption 
of  candidate  techniques  and  technologies  for  inclusion  in  the  acquisition 
organization's  standard  software  acquisition  process. _ _ 


Verifying  implementation 


Verification  1  Acquisition  innovation  management  activities  are  reviewed  by  acquisition 
organization  management  on  a  periodic  basis. 

I  The  primary  purpose  of  these  reviews  by  acquisition  organization  management  is  to 
i  provide  awareness  of,  and  insight  into,  acquisition  innovation  management  activities  at 
I  an  appropriate  level  of  abstraction  and  in  a  timely  manner.  The  reviews  verify  that 
acquisition  organization  policy  is  being  implemented.  The  time  between  reviews 
should  satisfy  the  needs  of  the  organization  and  may  be  lengthy,  as  long  as  adequate 
mechanisms  for  exception  reporting  are  available. _ 

Verification  2  Acquisition  innovation  management  activities  are  reviewed  by  the  project 
manager  on  both  a  periodic  and  event-driven  basis. 
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Comment  Resolutions:  April  1994. 
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U.S.  General  Accounting  Office,  hifoiwation  Technology:  A  Model  to  Help  Mctncigers  Decrease 
Acqtdsitioti  Risks  {GKOIJMIEC  8.1.6):  August  1990. 

U.S.  Navy,  Naval  Air  Systems  Command.  Software  Acquisition  Management  Maturity  Model, 
Draft:  September  1992. 
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92W0000154).  McLean,  Va.:  The  MITRE  Corporation,  July  1992. 
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acceptance  criteria  -  The  criteria  that  a  system  or  component  must  satisfy  in  order  to  be 
accepted  by  a  user,  customer,  or  other  authorized  entity  [IEEE-STD-610]. 

acceptcmce  testing  -  Formal  testing  conducted  to  determine  whether  or  not  a  system  satisfies 
its  acceptance  criteria  and  to  enable  the  customer  to  determine  whether  or  not  to  accept  the 
system  [ffiEE-STD-610]. 

acquisition  -  The  process  of  obtaining  through  contract. 

acquisition  organization  -  That  entity  which  has  the  oversight  responsibility  for  the  software 
acquisition  project  and  which  may  have  purview  over  the  acquisition  activities  of  a  number  of 
projects  or  contract  actions. 

acquisition  organization's  standard  software  acquisition  process  -  (See  software  acquisition 
process.) 

activity  -  Any  step  taken  or  function  performed,  either  mental  or  physical,  toward  achieving 
some  objective.  Activities  include  all  the  work  the  managers  and  technical  staff  do  to  perform 
the  tasks  of  the  project  and  organization. 

application  domain  -  A  bounded  set  of  related  systems  (i.e.,  systems  that  address  a  particular 
type  of  problem).  Development  and  maintenance  in  an  application  domain  usually  require 
special  skills  and/or  resources.  Examples  include  payroll  and  personnel  systems,  avionics, 
command  and  control  systems,  compilers,  and  expert  systems. 

appraise  -  To  evaluate  the  worth,  significance,  or  status  of. 

attributes  (of  software)  -  Characteristics  of  software  such  as  reliability,  maintainability, 
portability,  and  complexity.  These  characteristics  are  sometimes  referred  to  as  quality 
attributes. 

baseline  -  A  specification  or  product  that  has  been  formally  reviewed  and  agreed  upon,  that 
thereafter  serves  as  the  basis  for  further  development,  and  that  can  be  changed  only  through 
formal  change  control  procedures  [IEEE-STD-610]. 

capability  maturity  model  -  A  description  of  the  stages  through  which  organizations  evolve  as 
they  define,  implement,  measure,  control,  and  improve  their  processes.  The  model  provides  a 
guide  for  selecting  process  improvement  strategies  by  facilitating  the  determination  of  current 
process  capabilities  and  the  identification  of  the  issues  most  critical  to  quality  and  process 
improvement. 
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causal  analysis  -  The  analysis  of  defects  to  determine  their  underlying  root  cause. 

change  control  -  The  review,  approval/disapproval,  implementation,  tracking,  closure,  and 
status  reporting  of  proposed  changes  to  an  item  (change  management). 

commitment  -  A  pact  that  is  freely  assumed,  visible,  and  expected  to  be  kept  by  all  parties. 

common  features  -  The  subdivision  categories  of  the  S  A-CMM  key  process  areas.  The 
common  features  are  attributes  that  indicate  whether  the  implementation  and 
institutionalization  of  a  key  process  area  can  be  effective,  repeatable,  and  lasting.  The  SA- 
CMM's  common  features  are  the  following:  Commitment  to  perform,  Ability  to  perform. 
Activities  performed,  Measurement  and  analysis,  and  Verifying  implementation. 

configuration  -  In  configuration  management,  the  functional  and  physical  characteristics  of 
hardware  or  software  as  set  forth  in  technical  documentation  or  achieved  in  a  product  [lEEE- 
STD-610]. 

configuration  martagement  -  A  discipline  applying  techmcal  and  administrative  direction  and 
surveillance  to  identify  and  document  the  functional  and  physical  characteristics  of  a 
configuration  item,  control  changes  to  those  characteristics,  record  and  report  change 
processing  and  implementation  status,  and  verify  compliance  with  specified  requirements 
[IEEE-STD-610]. 

consistency  -  The  degree  of  uniformity,  standardization,  and  freedom  from  contradiction 
among  the  documents  or  parts  of  a  system  or  component  [IEEE-STD-610]. 

contract  -  A  binding  agreement  between  two  or  more  parties  that  establishes  the  requirements 
for  the  products  and  services  to  be  acquired. 

contract  integrity  -  The  adherence  and  compliance  to  contractual  and  legal  policies, 
regulations,  and  other  guidance. 

contract  terms  and  conditions  -  The  stated  legal,  financial,  and  administrative  aspects  of  a 
contract. 

contractor  -  The  entity  delivering  the  product  or  performing  the  service  being  acquired,  even 
if  that  entity  is  part  of  the  acquiring  organization. 

critical  paths  -  A  series  of  dependent  tasks  for  a  project  that  must  be  completed  as  planned  to 
keep  the  entire  project  on  schedule. 

defect  -  A  flaw  in  a  system  or  system  component  that  causes  the  system  or  component  to  fail 
to  perform  a  required  function. 


B-2 


CMU/SEI-96-TR-020 


Glossary  of  Terms 


L 

defined  level  -  (See  maturity  level.) 

defined  software  acquisition  process  -  (See  software  acquisition  process) 

deliverable  -  A  product  that  is  required  by  the  contract  to  be  delivered  to  the  acquirer  or  other 
designated  recipient. 

deviation  -  A  noticeable  or  marked  departure  from  the  appropriate  norm,  plan,  standard, 
procedure,  or  variable  being  reviewed. 

effective  -  Adequate  to  accomplish  the  intended  purpose. 

end  user  -  The  individual  or  group  who  will  use  the  system  for  its  intended  operational  use 
when  it  is  deployed  in  its  environment. 

end  user  representatives  -  A  selected  sample  of  end  users  who  represent  the  total  population 
of  end  users. 

evaluation  -  The  use  of  reviews,  inspections,  and/or  tests,  to  determine  that  a  software 
product  or  service  satisfies  specified  requirements. 

event-driven  basis  -  A  review  that  is  performed  based  on  the  occurrence  of  an  event  within 
the  project  (e.g.,  a  formal  review  or  the  completion  of  a  life  cycle  stage),  periodic 
review  for  contrast.) 

findings  -  The  conclusions  of  an  assessment,  evaluation,  audit,  or  review  that  identify  the  most 
important  issues,  problems,  or  opportunities  within  the  area  of  investigation. 

function  -  A  set  of  related  actions,  undertaken  by  individuals  or  tools  that  are  specifically 
assigned  or  fitted  for  their  roles,  to  accomplish  a  set  purpose  or  end. 

goals  -  The  aggregate  result  achieved  by  the  effective  implementation  of  the  common  features 
of  a  key  process  area.  The  goals  signify  the  scope  and  intent  of  each  key  process  area. 

group  -  An  assemblage  of  personnel  organized  to  serve  a  specific  purpose  or  accomplish  a 
task.  A  group  may  vary  from  a  single  individual  assigned  part  time,  to  several  part-time 
individuals  assigned  from  other  organizations,  to  several  individuals  dedicated  full-time. 

initial  level  -  (See  maturity  level) 

institutionalization  -  The  building  of  infrastructure  and  corporate  culture  that  supports 
methods,  practices,  and  procedures  so  that  they  are  the  ongoing  way  of  doing  business,  even 
after  those  who  originally  defined  them  are  gone. 
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instrumentation  -  The  application  of  instruments  (or  metrics)  for  observation,  measurement, 
or  control. 

key  process  area  -  A  cluster  of  related  activities  in  an  area  of  software  acquisition  that,  when 
performed  collectively,  achieve  a  set  of  goals  considered  important  for  establishing  process 
capability  in  that  area.  The  key  process  areas  have  been  defined  to  reside  at  a  single  maturity 
level.  These  are  the  principal  building  blocks  to  help  determine  the  software  acquisition 
process  capability  of  an  organization  and  understand  the  improvements  needed  to  advance  to 
higher  maturity  levels. 

life  cycle  -  (See  software  life  cycle) 

managed  and  controlled  -  Implies  that  the  version  of  the  work  product  in  use  at  a  given  time 
(past  or  present)  is  known  (i.e.,  version  control),  and  changes  are  incorporated  in  a  controlled 
manner  (i.e.,  change  control). 

manager  -  A  role  that  encompasses  providing  techmcal  and  administrative  direction  and 
control  to  individuals  performing  tasks  or  activities  within  the  manager's  area  of  responsibility. 
The  traditional  functions  of  a  manager  include  planning,  resourcing,  organizing,  directing,  and 
controlling  work  within  an  area  of  responsibility. 

maturity  level  -  A  well-defined  evolutionary  plateau  toward  achieving  a  mature  software 
acquisition  process.  The  five  maturity  levels  in  the  S  A-CMM  are  Initial,  Repeatable,  Defined, 
Quantitative,  and  Optimizing. 

measure  -  To  ascertain  the  characteristics  or  features  (extent,  dimension,  quantity,  capacity, 
and  capability)  of  something,  especially  by  comparing  with  a  standard. 

measurement  -  The  dimension,  capacity,  quantity,  or  amount  of  something  (e.g.,  300  source 
lines  of  code  or  seven  document  pages  of  design). 

method-  A  reasonably  complete  set  of  rules  and  criteria  that  establishes  a  precise  and 
repeatable  way  of  performing  a  task  and  arriving  at  a  desired  result. 

methodology  -  A  collection  of  methods,  procedures,  and  standards  that  defines  an  integrated 
synthesis  of  approaches. 

milestone  -  A  scheduled  event  for  which  some  individual  is  accountable  and  that  is  used  to 
measure  progress. 

non-developmental  item  -  An  item  of  software  that  is  available  for  delivery  and  acceptance 
prior  to  award  of  the  contract. 
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non-techmcal  software  requirements  -  Contractual  agreements,  conditions,  and  terms  that 
affect  the  activities  or  products  of  the  software  acquisition  project. 

offeror  -  A  contractor  who  submits  a  proposal  in  response  to  a  solicitation  package. 

optimizing  level  -  (See  maturity  level.) 

organization  -  The  parent  organization  of  the  acquisition  organization. 

organization's  measurement  program  -  The  set  of  related  elements  for  addressing  an 
organization's  measurement  needs.  It  includes  the  definition  of  organization-wide 
measurements,  methods  and  practices  for  collecting  organizational  measurements  and 
analyzing  data,  and  measurement  goals  for  the  organization. 

orientation  -  An  overview  or  introduction  to  a  topic. 

peer  review  -  A  review  of  a  software  work  product,  following  defined  procedures,  by  peers  of 
the  product's  producers  for  the  purpose  of  identifying  defects  and  improvements. 

periodic  review  -  A  review  that  occurs  at  specified  regular  time  intervals.  (See  event-driven 
basis  for  contrast.) 

policy  -  A  guiding  principle,  typically  established  by  senior  management,  that  is  adopted  by  an 
organization  or  project  to  influence  decisions. 

prime  contractor  -  An  individual,  partnership,  corporation,  or  association  that  administers  a 
subcontract  to  design,  develop,  and/or  manufacture  one  or  more  products. 

procedure  -  A  written  description  of  a  course  of  action  to  be  taken  to  perform  a  given  task 
[lEEE-STD-blO]. 

process  -  A  set  of  activities  performed  for  a  given  purpose  (e.g.,  the  software  acquisition 
process). 

process  capability  -  The  range  of  expected  results  that  can  be  achieved  by  following  a 
process.  (See  process  performance  for  contrast.) 

process  capability  baseline  -  A  documented  characterization  of  the  range  of  expected  results 
that  would  normally  be  achieved  by  following  a  specific  process  under  typical  circumstances. 
A  process  capability  baseline  is  typically  established  at  an  organizational  level.  {See process 
perfomiance  baseline  for  contrast.) 
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process  descriptions  -  Documentation  that  specifies,  in  a  complete,  precise,  verifiable  manner, 
the  requirements,  design,  behavior,  or  other  characteristics  of  a  process.  It  may  also  include 
the  procedures  for  determining  whether  these  provisions  have  been  satisfied. 

process  measurement  -  The  set  of  definitions,  methods,  and  activities  used  to  take 
measurements  of  a  process  and  its  resulting  products  for  the  purpose  of  characterizing  and 
understanding  the  process. 

process  performance  -  A  measure  of  the  actual  results  achieved  by  following  a  process.  (See 
process  capability  for  contrast.) 

process  performance  baseline  -  A  documented  characterization  of  the  actual  results  achieved 
by  following  a  process.  A  process  performance  baseline  is  typically  established  at  the  project 
level,  although  the  initial  process  performance  baseline  will  usually  be  derived  fi’om  the 
process  capability  baseline.  (See process  capability  baseline  for  contrast.) 

project  -  An  undertaking  that  is  focused  on  acquiring  a  specific  product.  The  product  may 
include  hardware,  software,  and  services.  Typically,  a  project  has  its  own  fianding,  cost 
accounting,  and  delivery  schedule. 

project  manager  -  The  role  with  total  business  responsibility  for  an  entire  project;  the 
individual  who  directs,  controls,  administers,  and  regulates  a  project  acquiring  software,  a 
hardware/software  system,  or  services.  The  project  manager  is  the  individual  ultimately 
responsible  to  the  end  user. 

project  office  -  The  aggregate  of  individuals  assigned  the  primary  responsibility  for  software 
acquisition  in  the  contracted  effort.  A  project  oflBce  may  vary  in  size  from  a  single  individual 
assigned  part  time  to  a  large  organization  assigned  full  time. 

project  team  -  All  individuals  that  have  an  assigned  software  acquisition  responsibility  in  the 
contracted  effort.  A  project  team  may  vary  in  size  from  a  single  individual  assigned  part  time 
to  a  large  organization  assigned  full  time. 

project's  defined  software  acquisition  process  -  (See  software  acquisition  process.) 

quality  -  (1)  The  degree  to  which  a  system  or  system  component  meets  specified 
requirements.  (2)  The  degree  to  which  a  system  or  system  component  meets  user  needs  or 
expectations  [IEEE-STD-610]. 

quality  assurance  -  (See  software  quality  assurance.) 

quantitative  control  -  Any  quantitative  or  statistically-based  technique  appropriate  to  analyze 
a  software  acquisition  process,  identify  special  causes  of  variations  in  the  performance  of  the 
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software  acquisition  process,  and  bring  the  performance  of  the  software  acquisition  process 
within  well-defined  limits. 

quantitative  level  -  (See  maturity  level.) 

repeatable  level  -  (See  maturity  level.) 

required  training  -.  Training  required  by  the  acquisition  organization.  (See  training  for 
contrast.) 

risk  -  Uncertainty  of  achieving  expectations. 

risk  management  -  The  process  associated  with  identifying,  evaluating,  mitigating,  and 
controlling  project  risks. 

role  -  A  unit  of  defined  responsibilities  that  may  be  assumed  by  one  or  more  individuals. 

software  acquisition  management  personnel  -  Those  individuals  who  are  trained,  educated,  or 
experienced  in  software  acquisition  management  and  who  are  either  assigned  to  or  support  the 
project  team  in  the  performance  of  software  acquisition  activities. 

software  acquisition  plans  -  The  collection  of  plans,  both  formal  and  informal,  used  to  express 
how  software  acquisition  activities  will  be  performed;  for  example,  the  Software  Acquisition 
Risk  Management  Plan  or  Project  Management  Plan. 

software  acquisition  process  -  A  set  of  activities,  methods,  practices,  and  transformations  that 
people  use  to  acquire  software  and  the  associated  products. 

►  acquisition  organization’s  standard  software  acquisition  process  -  The 
acquisition  organization's  fundamental  software  acquisition  process  which 
guides  the  establishment  of  each  project's  defined  software  acquisition  process. 

►  project's  defined  software  acquisition  process  -  The  project's  tailored  version 
of  the  acquisition  organization's  standard  software  acquisition  process. 

software  acquisition  process  assets  -  A  collection  of  entities,  maintained  by  an  organization, 
for  use  by  projects  in  developing,  tailoring,  maintaining,  and  implementing  their  software 
acquisition  processes. 

Some  examples  of  these  software  acquisition  process  assets  include: 

the  acquisition  organization's  standard  software  acquisition  process, 
descriptions  of  the  software  life  cycles  approved  for  use, _ 
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the  guidelines  and  criteria  for  tailoring  the  acquisition  organization's 
standard  software  acquisition  process, 
the  organization's  software  acquisition  process  database,  and 
a  librar>^  of  software  acquisition  process-related  documentation. 


Any  entity  that  the  organization  considers  useful  in  performing  the  activities  of  process 
deMtion  and  maintenance  could  be  included  as  a  process  asset. 

software  acquisition  process  group  -  This  group  is  responsible  for  the  definition, 
improvement^  and  maintenance  of  the  acquisition  organization's  standard  software  acquisition 
process  and  related  process  assets,  including  guidelines  for  all  projects  to  tailor  the  standard 
software  acquisition  process  to  their  specific  situations.  It  coordinates  process  activities  with 
the  software  projects  and  related  elements  of  the  organization. 

software  acquisition  process-related  documentation  -  Documents  and  document  fragments 
that  may  be  of  use  to  future  project  teams  when  tailoring  the  acquisition  organization's 
standard  software  acquisition  process.  The  examples  may  cover  subjects  such  as  a  project's 
defined  software  acquisition  process,  standards,  procedures,  software  acquisition  risk 
management  plans,  and  training  materials. 

software  acquisition  process  repository  -  A  collection  of  software  acquisition  process 
information  (e.g.,  estimated  and  actual  data  on  software  project  size,  effort,  and  cost;  and 
project  team  productivity  and  quality  data)  gathered  from  the  software  acquisition  projects 
that  is  maintained  by  the  acquisition  organization  to  support  its  software  acquisition  definition 
and  improvement  activities. 

software  acquisition  project  -  An  undertaking  that  is  focused  on  acquiring  the  software 
components  and  associated  documentation  of  a  system.  A  software  project  may  be  part  of  a 
project  building  a  hardware/software  system. 

software  acquisition-related  group  -  A  collection  of  individuals  (both  managers  and  technical 
staff)  representing  a  software  discipline  that  supports,  but  is  not  directly  responsible  for, 
software  acquisition.  Examples  of  software  disciplines  include  software  configuration 
management  and  software  quality  assurance. 

software  architecture  -  The  organizational  structure  of  the  software  or  module  [lEEE-STD- 

6i0]. 

software  engineering  group  -  The  collection  of  individuals  (both  managers  and  techmcal  staff) 
who  have  responsibility  for  software  development  and  maintenance  activities  (i.e., 
requirements  analysis,  design,  code,  and  test)  for  a  project.  Groups  performing  software- 
related  work,  such  as  the  software  quality  assurance  group  and  the  software  configuration 
management  group,  are  not  included  in  the  software  engineering  group. 
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software  engineering  personnel  -  Those  individuals  who  are  trained,  educated,  or  experienced 
in  software  engineering  and  who  are  either  assigned  to  or  support  the  project  team  in  the 
performance  of  software  acquisition  activities. 

software  life  cycle  -  The  period  of  time  that  begins  when  a  software  product  is  conceived  and 
ends  when  the  software  is  no  longer  available  for  use.  The  software  life  cycle  t5q)ically 
includes  a  concept  phase,  requirements  phase,  design  phase,  implementation  phase,  test  phase, 
installation  and  checkout  phase,  operation  and  maintenance  phase,  and,  sometimes,  retirement 
phase  [ffiEE-STD-610]. 

software  quality  assurance  -  (1)  A  planned  and  systematic  pattern  of  all  actions  necessary  to 
provide  adequate  confidence  that  a  software  work  product  conforms  to  established  technical 
requirements.  (2)  A  set  of  activities  designed  to  evaluate  the  process  by  which  software  work 
products  are  developed  and/or  maintained. 

software-related  contractual  requirements  -  All  technical  and  non-technical  requirements 
related  to  the  software  portion  of  the  acquisition. 

software  support  -  The  process  of  modifying  a  software  system  or  component  after  delivery  to 
correct  faults,  improve  performance  or  other  attributes,  or  adapt  to  a  changed  environment. 
[ffiEE-STD-610] 

solicitation  package  -  When  seeking  suppliers  for  a  particular  acquisition,  it  is  the  information 
distributed  which  tells  the  interested  bidders  what  the  requirements  are,  how  to  prepare  their 
proposals,  how  proposals  will  be  evaluated,  and  when  to  submit  their  proposals.  Sometimes 
called  Request  for  Proposals  (RFP). 

standard  -  Mandatory  requirements  employed  and  enforced  to  prescribe  a  disciplined  uniform 
approach  to  software  development  or  acquisition. 

standard  software  acquisition  process  -  (See  software  acquisition  process.) 

statement  of  work  -  A  description  of  all  the  work  required  to  complete  a  project,  which  is 
provided  by  the  customer. 

subcontractor  -  An  individual,  partnership,  corporation,  or  association  that  contracts  with  an 
organization  (i.e.,  the  prime  contractor)  to  design,  develop,  and/or  manufacture  one  or  more 
products. 

system  requirement  -  A  condition  or  capability  that  must  be  met  or  possessed  by  a  system  or 
system  component  to  satisfy  a  condition  or  capability  needed  by  a  user  to  solve  a  problem 
[ffiEE-STD-610]. 
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system  requirements  allocated  to  software  -  The  subset  of  the  system  requirements  that  are  to 
be  implemented  in  the  software  components  of  the  system. 

tailor  -  To  modify  a  process,  standard,  or  procedure  to  better  match  process  or  product 
requirements. 

technical  software  requirements  -  The  system  requirements  allocated  to  software. 

technology  -  The  application  of  science  and/or  engineering  in  accomplishing  a  particular 
result. 

traceability  -  The  ability  to  trace,  in  both  the  forward  and  backward  directions,  the  lineage  of 
a  requirement  from  its  first  level  inception  and  subsequent  refinement  to  its  implementation  in 
a  software  product  and  the  documentation  associated  with  the  software  product. 

training  -  Project  team  training.  (See  required  training  for  contrast.) 

training  group  -  The  collection  of  individuals  (both  managers  and  staff)  who  are  responsible 
for  coordinating  and  arranging  the  training  activities  for  an  organization.  This  group  typically 
prepares  and  conducts  most  of  the  training  courses  and  coordinates  use  of  other  training 
vehicles. 

trainwg program  -  The  set  of  related  elements  that  focuses  on  addressing  an  organization's 
training  needs.  It  includes  an  organization's  training  plan,  training  materials,  development  of 
training,  conduct  of  training,  training  facilities,  evaluation  of  training,  and  maintenance  of 
training  records. 

transition  -  The  process  of  transferring  responsibility  for  the  acquired  software  products  from 
the  project  manager  to  the  software  support  organization. 

user  -  (See  end  user.) 

verify  -  To  prove  to  be  true  by  demonstration,  evidence,  or  testimony. 
waiver  -  A  document  stating  a  cancellation  or  reduction  of  a  requirement. 
written  procedure  -  (See  procedure) 
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Appendix  C;  Summary  of  Key  Process  Areas 

This  appendix  provides  a  summary  of  each  of  the  SA-CMM  key  process  areas.  It  can  be  used  to 
get  a  "quick  look"  at  each  key  process  area  through  its  introduction,  goals,  and  top-level 
activities.  It  does  not  provide  the  institutionalization  features  (i.e..  Commitment  to  perform. 
Ability  to  perform.  Measurement  and  analysis,  and  Verifying  implementation)  or  the  details  within 
the  activities.  It  is  intended  for  informational  purposes,  not  for  determining  compliance  with  the 
requirements  of  the  key  process  areas. 

The  institutionalization  features  must  be  in  place  to  ensure  that  the  key  process  areas  are 
implemented  appropriately  and  effectively,  are  solidly  established,  will  be  maintained  over  time, 
and  can  be  applied  successfully  to  new  projects.  Commitment  to  perform  involves  establishing 
organizational  policies  and  management  sponsorship.  Ability  to  perform  involves  providing 
resources,  organizational  structures,  and  training.  Measurement  and  analysis  includes  examples  of 
measurements  that  could  be  taken  to  determine  the  status  and  effectiveness  of  the  Activities 
performed.  Verifying  implementation  encompasses  reviews  by  management. 

To  appropriately  establish  a  key  process  area,  the  full  set  of  common  features  and  the  detailed 
activities  must  be  used. 
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Level  1:  The  Initial  Level 

There  are  no  key  process  areas  at  Level  1 . 
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Level  2:  Software  Acquisition  Planning 


The  purpose  of  Software  Acquisition  Planning  is  to  ensure  that  reasonable  planning  for  the 
software  acquisition  is  conducted  and  that  all  elements  of  the  project  are  included. 

Software  Acquisition  Planning  involves  the  preparation  for  software-related  areas  in  system  level 
planning  such  as  early  budgetary  action,  schedule  determination,  acquisition  strategy,  risk 
identification,  and  software  requirements  definition.  There  are  other  traditional  software 
acquisition  planning  activities  that  must  be  performed  in  the  context  of  the  system  as  a  whole  and 
in  coordination  with  the  project  team  (e.g.,  system  requirements  development,  hardware/software 
partitioning,  system  level  software  requirements  allocation,  and  solicitation  management). 
Software  Acquisition  Planning  also  involves  planning  all  aspects  of  the  software  acquisition 
project.  Software  acquisition  planning  documentation  provides  for  implementation  of  all  software 
acquisition-related  policies. 

Software  acquisition  planning  begins  with  the  earliest  identification  of  a  role  for  software  in  the 
system  to  be  acquired.  The  process  starts  when  reasonable  resources  are  assigned  to  form  a 
project  team  for  the  acquisition,  independent  of  whether  or  not  the  team  is  formally  constituted  as 
an  organizational  entity.  Software  acquisition  planning  provides  for  conducting  and  documenting 
software  acquisition  planning  activities  and  participation  in  system  level  planning  activities  as 
appropriate. 
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The  goals  of  Software  Acquisition  Planning  are: 

1 .  Software  acquisition  planning  documents  are  prepared  early  in  the  acquisition  process  and 
prior  to  contractual  actions  to  acquire  software  products  and  services. 

2.  Software  acquisition  plans  encompass  the  total  software  acquisition  effort. 

The  top-level  activities  performed  for  Software  Acquisition  Planning  are: 

1 .  Software  acquisition  planning  personnel  are  involved  in  system  acquisition  planning. 

2.  The  software  acquisition  strategy  for  the  project  is  developed  and  documented. 

3.  The  project's  software  acquisition  planning  is  documented  and  the  planmng  documentation 
is  maintained  over  the  life  of  the  project. 

4.  Life  cycle  support  of  the  software  is  included  in  software  acquisition  planning 
documentation. 

5.  Life  cycle  cost  and  schedule  estimates  for  the  software  products  and  services  being 
acquired  are  prepared  and  independently  reviewed. 
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Level  2:  Solicitation 

The  purpose  of  Solicitation  is  to  prepare  a  solicitation  package  that  identifies  the  needs  of  a 
particular  acquisition  and  to  select  a  contractor  who  is  best  capable  of  satisfying  the  requirements 
of  the  contract. 

Solicitation  involves  planning  and  performing  the  activities  necessary  to  issue  the  solicitation 
package,  preparing  for  the  evaluation  of  responses,  conducting  the  evaluation,  conducting 
negotiations,  and  awarding  the  contract.  Solicitation  ends  with  contract  award. 
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The  goals  of  Solicitation  are: 


1 .  The  selection  official  selects  a  contractor  who  is  qualified  to  satisfy  the  contract's 
requirements  for  the  project's  software-related  products  and  services. 

2.  Solicitation  activities  are  conducted  in  a  manner  compliant  with  relevant  laws,  regulations, 
policies,  and  guidance, 

3 .  The  software  portion  of  the  solicitation  package  satisfies  the  needs  of  the  acquisition. 

The  top-level  activities  performed  for  Solicitation  are: 

1 .  The  project  team  performs  its  activities  in  accordance  with  its  documented  solicitation 
plans. 

2.  The  project  team  performs  its  activities  in  accordance  with  its  documented  proposal 
evaluation  plans. 

3.  Cost  and  schedule  estimates  for  the  software  products  and  services  being  sought  are 
prepared. 

4.  Software  cost  and  schedule  estimates  are  independently  reviewed  for  comprehensiveness 
and  realism 

5.  The  project  team  takes  action  to  ensure  the  mutual  understanding  of  software 
requirements  and  plans  prior  to  contract  award. 
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Level  2:  Requirements  Development  and  Management 


The  purpose  of  Requirements  Development  and  Management  is  to  establish  a  common  and 
unambiguous  definition  of  software-related  contractual  requirements  that  is  understood  by  the 
project  team,  end  user,  and  the  contractor.  Software-related  contractual  requirements  consist  of 
technical  requirements  (system  requirements  allocated  to  software)  and  non-techmcal 
requirements  (contractual  agreements,  conditions,  and  terms  affecting  the  software  portion  of  the 
acquisition).  This  key  process  area  is  divided  into  two  subprocesses;  development  of  software- 
related  contractual  requirements  and  the  management  of  these  requirements  for  the  duration  of 
the  acquisition. 

Software  requirements  development  involves  those  activities  in  which  system  level  requirements 
are  decomposed  and  allocated  to  software.  To  ensure  software  is  appropriately  addressed  during 
system  requirements  definition  and  solicitation  package  preparation,  the  project  team  participates 
with  the  overall  system  acquisition  team.  This  activity  often  involves  direct  participation  from  the 
end  user  to  ensure  that  system-level  requirements  are  well  understood. 

Software  requirements  management  involves  establishing  and  maintaining  agreement  among  the 
project  team,  including  the  end  user,  and  contractor  with  respect  to  the  software-related 
contractual  requirements.  It  involves  baselining  the  software  requirements  and  controlling  all 
subsequent  requirements  changes.  The  contract  and  this  key  process  area  address  both  technical 
and  non-technical  software  requirements. 

Requirements  development  and  management  begins  with  the  translation  of  operational  or  end  user 
requirements  into  solicitation  documentation  (e.g.,  specifications)  and  ends  with  the  transfer  of 
responsibility  for  the  support  of  the  software  products. 

Software-related  contractual  requirements  define  the  scope  of  the  software  effort.  Software- 
related  contractual  requirements  are  incorporated  into  software  project  plans,  activities,  and 
products  in  an  orderly  manner.  Requirements  management  ensures  that  software  requirements  are 
unambiguous,  traceable,  verifiable,  documented,  and  controlled. 
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The  goals  of  Requirements  Development  and  Management  are: 

1 .  Software-related  contractual  requirements  are  developed  and  maintained  in  conjunction 
with  the  end  user  and  other  affected  groups. 

2.  Software-related  contractual  requirements  are  unambiguous,  traceable,  and  verifiable. 

3 .  The  software-related  contractual  requirements  baseline  is  established  and  managed. 

The  top-level  activities  performed  for  Requirements  Development  and  Management  are: 

1 .  The  project  team  performs  its  activities  in  accordance  with  its  documented  requirements 
development  and  management  plans. 

2.  The  project  team  develops  and  baselines  the  software-related  contractual  requirements  and 
places  them  under  change  control  early  in  the  project,  but  not  later  than  release  of  the 
solicitation  package. 

3 .  The  project  team  appraises  system  requirements  change  requests  for  their  impact  on  the 
software  being  acquired. 

4.  The  project  team  appraises  all  changes  to  the  software-related  contractual  requirements 
for  their  impact  on  performance,  architecture,  supportability,  system  resource  utilization, 
and  contract  schedule  and  cost. 

5.  Bi-directional  traceability  between  the  software-related  contractual  requirements  and  the 
contractor's  software  work  products  and  services  is  maintained  throughout  the  effort. 
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Summary  of  KPAs 


Level  2:  Project  Management 


The  purpose  of  Project  Management  is  to  manage  the  activities  of  the  project  office  and 
supporting  contract(s)  to  ensure  a  timely,  efficient,  and  effective  software  acquisition. 

Project  Management  involves  planning,  organizing,  staffing,  directing,  and  controlling  project 
office  activities,  such  as  determining  project  tasks,  estimating  software  size  and  cost,  scheduling 
activities  and  tasks,  training,  leading  the  assigned  persoimel,  and  accepting  software  products  and 
services. 

Project  management  begins  when  the  project  office  is  officially  chartered  and  terminates  when  the 
acquisition  is  completed. 
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Summary  of  KPAs 


The  goals  of  Project  Management  are: 

1 .  Project  management  activities  provide  effective  management  control  of  the  software 
acquisition  project. 

2.  The  performance,  cost,  and  schedule  objectives  of  the  software  acquisition  project  are 
defined,  measured,  and  controlled  throughout  the  software  acquisition. 

3.  Problems  discovered  during  the  software  acquisition  are  managed  and  controlled. 

The  top-level  activities  performed  for  Project  Management  are: 

1 .  The  project  team  performs  its  activities  in  accordance  with  its  documented  software 
acquisition  management  plans. 

2.  The  organization  of  the  project  provides  for  the  management  of  all  project  functions. 

3 .  The  software  acquisition  management  activities  of  the  project  team  are  directed  to 
accomplish  the  project's  objectives. 

4.  The  software  acquisition  management  activities  of  the  project  team  are  controlled. 

5.  The  project  team  implements  a  corrective  action  system  for  the  identification,  recording, 
tracking,  and  correction  of  problems  discovered  during  the  software  acquisition. 

6.  The  project  team  tracks  project  status,  execution,  funding,  and  expenditures  and  takes 
action. 
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Summary  of  KPAs 


Level  2:  Contract  Tracking  and  Oversight 

The  purpose  of  Contract  Tracking  and  Oversight  is  to  ensure  that  the  software  activities  under 
contract  are  being  performed  in  accordance  with  contractual  requirements,  and  that  evolving 
products  and  services  will  satisfy  contractual  requirements. 

Contract  Tracking  and  Oversight  involves  providing  ongoing  inputs  and  guidance  to  the 
contractor's  effort  and  identifies  risks  and  problems  in  the  effort. 

Contract  tracking  and  oversight  begins  tvith  the  award  of  the  contract  and  ends  at  the  conclusion 
of  the  contract's  period  of  performance. 

The  contract  provides  the  binding  agreement  for  establishing  the  requirements  for  the  software 
products  and  services  to  be  acquired.  It  establishes  the  mechanism  to  allow  the  project  team  to 
oversee  the  contractor's  software  activities  and  evolving  products  and  to  evaluate  any  software 
products  and  services  being  acquired.  It  also  provides  the  vehicle  for  mutual  understanding 
between  the  project  team  and  the  contractor  of  the  software  requirements  of  the  contract.. 
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Summary  ofKPAs 


The  goals  of  Contract  Tracking  and  Oversight  are: 

1 .  The  acquired  software  products  and  services  satisfy  contractual  requirements. 

2.  The  contractor's  software  engineering  effort  complies  with  contract  requirements. 

3 .  The  project  team  and  contractor  maintain  ongoing  communication  and  commitments  are 
agreed  to  by  both  parties. 

4.  The  contract,  and  any  changes,  adhere  to  relevant  laws,  policies,  regulations,  and  other 
planned  guidance  and  is  consistent  with  project  software  acquisition  requirements. 

The  top-level  activities  performed  for  Contract  Tracking  and  Oversight  are: 

1 .  The  project  team  performs  its  activities  in  accordance  with  its  documented  contract 
tracking  and  oversight  plans. 

2.  The  project  team  reviews  required  contractor  software  planning  documents  which,  when 
satisfactory,  are  used  to  oversee  the  contractor's  software  engineering  effort. 

3 .  The  project  team  conducts  periodic  reviews  and  interchanges  with  the  contractor. 

4.  The  project  team  reviews  and  tracks  the  development  of  the  software  engineering 
environment  required  to  provide  life  cycle  support  for  the  acquired  software. 

5.  Any  problems  or  issues  found  by  the  project  team  during  contract  tracking  and  oversight 
are  recorded  in  the  appropriate  corrective  action  system  and  tracked  to  closure. 

6.  The  project  team  maintains  the  integrity  of  the  contract  throughout  the  contract 
performance  period. 
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Summary  of  KPAs 


Level  2:  Evaluation 


The  purpose  of  Evaluation  is  to  determine  that  the  acquired  software  products  and  services  satisfy 
contract  requirements  prior  to  acceptance  and  transition  to  support. 

Evaluation  involves  the  development  of  technical  and  non-technical  requirements  for  the 
evaluation  approach,  including  acceptance  criteria,  which  are  incorporated  into  both  the 
solicitation  package  and  the  contract.  Evaluations  are  conducted  during  contract  performance 
and  results  are  analyzed  to  determine  acceptability  of  the  software  products  and  services. 
Evaluation  activities  are  designed  to  reduce  interference  with  contractor-performed  evaluations 
and  to  reduce  duplication  of  evaluation  efforts.  Evaluation  builds  on  the  activities  that  establish 
and  verify  the  contractual  requirements.  Evaluation  interacts  with  the  Contract  Tracking  and 
Oversight  key  process  area. 

Evaluation  begins  with  development  of  the  system  requirements  and  ends  when  the  software 
acquisition  is  completed. 
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Summary  of  KPAs 


The  goals  of  Evaluation  are: 

1 .  Evaluations  provide  an  objective  basis  to  support  the  decision  for  acceptance  of  the 
software  products  and  services. 

2.  Evaluations  are  planned  to  provide  an  integrated  approach  which  satisfies  all  evaluation 
requirements  and  maximizes  efficiency  of  the  activities. 

The  top-level  activities  performed  for  Evaluation  are: 

1 .  The  project  team  performs  its  activities  in  accordance  with  its  documented  evaluation 
plans. 

2.  The  project's  evaluation  requirements  are  developed  in  conjunction  with  the  development 
of  the  system  or  software  technical  requirements, 

3.  The  evaluation  requirements  are  incorporated  into  the  solicitation  package  and  resulting 
contract. 

4.  The  project  team  assesses  contractor's  performance  for  compliance  with  evaluation 
requirements. 

5.  Planned  evaluations  are  performed  on  the  acquired  software  products  and  services  prior  to 
acceptance  for  operational  use. 

6.  Results  of  the  evaluations  are  analyzed  and  compared  to  the  contract's  requirements  to 
establish  an  objective  basis  to  support  the  decision  to  accept  the  products  and  services  or 
to  take  further  action. 
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Level  2:  Transition  to  Support 


The  purpose  of  Transition  to  Support  is  to  provide  for  the  transition  of  the  software  products 
being  acquired  to  the  eventual  software  support  organization.  The  necessary  resources  are 
identified,  budgeted  for,  and  are  available  when  needed.  The  designated  software  support 
organization  is  fully  prepared  to  accept  responsibility  for  the  software  products  in  time  to  ensure 
uninterrupted  support. 

Transition  to  Support  involves  developing  and  implementing  the  plans  for  transitioning  the 
acquired  software  products.  It  also  involves  ensuring  that  the  contractor  and  the  software 
support  organization  are  informed  on  the  contents  of  the  software  engineering  and  support 
environments.  The  project  team  provides  for  an  orderly,  smooth  transition  of  the  software 
products  fi-om  the  contractor  to  the  software  support  organization. 

Transition  to  support  begins  with  the  earliest  definition  of  software  requirements  and  ends  when 
the  responsibility  for  the  software  products  is  turned  over  to  the  software  support  organization. 
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Summary  of  KPAs 


The  goals  of  Transition  to  Support  are; 

1 .  The  software  support  organization  has  the  capacity  to  provide  the  required  support  upon 
assumption  of  responsibility  for  the  software  products. 

2.  There  is  no  loss  in  continuity  of  support  to  the  software  products  during  transition  from 
the  contractor  to  the  software  support  organization. 

3 .  Configuration  management  is  maintained  throughout  the  transition. 

The  top-level  activities  performed  for  Transition  to  Support  are: 

1 .  The  project  team  performs  its  activities  in  accordance  with  its  documented  transition  to 
support  plans. 

2.  Responsibility  for  the  software  products  is  transferred  only  after  the  software  support 
organization  demonstrates  its  capability  to  modify  and  support  the  software  products. 

3 .  The  project  team  oversees  the  configuration  control  of  the  software  products  throughout 
the  transition. 
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Summary  of  KPAs 


Level  3:  Process  Definition  and  Maintenance 


The  purpose  of  Process  Definition  and  Maintenance  is  to  establish  the  acquisition  organization's 
standard  software  acquisition  process  and  an  organizational  responsibility  for  stabilizing  and 
maintaining  the  standard  software  acquisition  process. 

Process  Definition  and  Maintenance  involves  understanding  the  organization's  and  projects' 
software  acquisition  processes,  collecting  a  set  of  software  acquisition  process  assets,  and 
coordinating  efforts  to  appraise  and  improve  software  acquisition  processes. 

The  acquisition  organization  provides  the  long-term  commitments  and  resources  to  establish  and 
maintain  a  software  acquisition  process  group.  This  group  is  responsible  for  the  definition, 
maintenance,  and  improvement  of  the  acquisition  organization's  standard  software  acquisition 
process  and  other  process  assets,  including  guidelines  for  all  projects  to  tailor  the  standard 
software  acquisition  process  to  their  specific  situations.  It  coordinates  process  activities  with  the 
software  projects  and  related  elements  of  the  organization. 


C-18 


CMU/SEI-96-TR-020 


Summary  ofKPAs 


The  goals  of  Process  Definition  and  Maintenance  are: 

1 .  A  standard  software  acquisition  process  for  the  acquisition  organization  is  defined, 
managed,  and  controlled. 

2.  Process  definition  and  maintenance  activities  are  coordinated  across  the  acquisition 
organization. 

3 .  Information  relating  to  the  use  of  the  acquisition  organization's  standard  software 
acquisition  process  by  the  software  acquisition  projects  is  collected,  analyzed,  and  made 
accessible. 

The  top-level  activities  performed  for  Process  Definition  and  Maintenance  are: 

1 .  The  acquisition  organization  performs  its  activities  in  accordance  with  its  documented 
process  definition  and  maintenance  plans. 

2.  The  acquisition  organization's  standard  software  acquisition  process  is  defined  and 
maintained  in  accordance  with  its  documented  process  definition  and  maintenance  plans. 

3 .  The  acquisition  organization's  standard  software  acquisition  process  is  appraised 
periodically  and  action  plans  developed  to  address  the  findings  of  the  appraisal. 

4.  The  acquisition  organization's  and  projects'  activities  for  defining  and  maintaining  their 
software  acquisition  processes  are  coordinated  at  the  organization  level. 

5 .  Guidelines  and  criteria  for  a  project's  selection  and  tailoring  of  the  acquisition 
organization's  standard  software  acquisition  process  are  developed  and  maintained. 

6.  An  organizational  repository  of  software  acquisition  process  information  is  established, 
managed,  controlled,  and  maintained  to  support  process  definition  and  maintenance 
activities. 

7.  Project  teams  are  informed  of  the  acquisition  organization's  and  projects'  activities  for 
process  definition  and  maintenance. 
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Summary  of  KPAs 


Level  3:  Project  Performance  Management 


The  purpose  of  Project  Performance  Management  is  to  manage  the  software  acquisition  project 
according  to  a  defined  software  acquisition  process. 

Project  Performance  Management  involves  developing  the  project's  defined  software  acquisition 
process  and  managing  the  acquisition  using  this  defined  process.  The  project's  defined  software 
acquisition  process  is  tailored  from  the  acquisition  organization's  standard  software  acquisition 
process  to  address  specific  attributes  of  the  project. 

The  project's  management  plans  are  based  on  the  project's  defined  software  acquisition  process. 
These  plans  describe  how  the  project's  defined  software  acquisition  process  will  be  implemented 
and  managed. 

The  basic  practices  for  estimating,  planning,  and  tracking  a  software  acquisition  project  are 
established  in  the  Software  Acquisition  Planning,  Project  Management,  and  Contract  Tracking 
and  Oversight  key  process  areas.  The  emphasis  in  Project  Performance  Management  at  Level  3 
shifts  from  reacting  to  acquisition  problems  and  issues  to  anticipating  these  problems  and  acting 
to  mitigate  the  risk. 
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Summary  of  KPAs 


The  goals  of  Project  Performance  Management  are: 

1 .  The  project  is  managed  according  to  a  coherent  defined  software  acquisition  process. 

2.  Effective  communication  and  teamwork  among  affected  groups  exists. 

3.  An  integrated  management  approach  is  used  to  achieve  project  management's  software 
acquisition  objectives. 

The  top-level  activities  performed  for  Project  Performance  Management  are: 

1 .  The  project's  defined  software  acquisition  process  is  developed  and  documented  by 
tailoring  the  acquisition  organization's  standard  software  acquisition  process  according  to 
the  organization's  tailoring  guidelines. 

2.  The  project  team  develops  and  maintains  the  Project  Management  Plan  in  accordance  with 
the  acquisition  organization's  standard  software  acquisition  process. 

3.  The  project  team's  software  acquisition  management  activities  are  performed  in 
accordance  with  the  Project  Management  Plan. 

4.  The  project’s  defined  software  acquisition  process  is  revised  as  required  to  remain 
consistent  with  current  project  objectives. 

5.  The  project  team  coordinates  its  activities  with  other  organizations  and  activities 
supporting  the  project. 

6.  The  acquisition  organization's  software  acquisition  process  repository  is  used  for  project 
planning,  estimating,  and  management. 

7.  Critical  dependencies  are  identified,  negotiated,  and  managed. 

8.  The  project  team  performs  periodic  reviews  to  ensure  current  and  projected  needs  of  the 
end  user  will  be  satisfied. 

9.  Measurements  are  used  to  determine  project  team  performance  and  trends  analyzed. 

10.  The  project  team  identifies  and  analyzes  risks  and  identifies  specific  risk  handling  actions 
for  those  risks. 

1 1 .  The  project  team's  software  acquisition  lessons  learned  are  identified,  documented,  and 
entered  into  the  acquisition  organization's  software  acquisition  process  repository. 
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Summary  of  KPAs 


Level  3:  Contract  Performance  Management 


The  purpose  of  Contract  Performance  Management  is  to  implement  a  defined  contract 
management  process,  the  objective  of  which  is  to  acquire  software  products  and  services  that 
satisfy  contract  requirements. 

Contract  Performance  Management  involves  appraising  the  contractor's  software  engineering 
performance  and  the  quality  of  the  evolving  products  and  ongoing  services.  Based  on  the  results 
of  the  appraisals,  the  acquisition  may  be  adjusted.  The  process  includes  evaluation  of  final 
products  and  services  to  determine  satisfaction  of  contractual  requirements.  The  emphasis  in 
contract  performance  management  is  to  be  proactive  regarding  contractor  performance  and 
contract  compliance  issues  and  to  minimize  the  effects  of  these  issues.  Additional  activities 
include  contributing  to  the  project's  risk  management  activities,  fostering  an  environment  of 
mutual  cooperation  with  the  contractor,  and  identifying  improvements  to  the  contract 
performance  management  process. 

The  contract  performance  management  process  integrates  contract  performance  management 
activities  with  other  project  management  activities.  Contract  Performance  Management  builds  on 
the  Contract  Tracking  and  Oversight  and  Evaluation  key  process  areas.  Contract  performance 
management  begins  when  the  contract  is  awarded  and  ends  at  the  conclusion  of  the  contract's 
period  of  performance. 
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The  goals  of  Contract  Performance  Management  are: 

1 .  Contract  performance  management  activities  are  conducted  in  a  manner  that  ensures 
satisfaction  of  software  contractual  requirements. 

2.  The  quality  of  contractor  performance,  products,  and  services  is  appraised  throughout  the 
contract's  period  of  performance  to  identify  risks  and  take  action  to  mitigate  those  risks  as 
early  as  possible. 

3.  A  cooperative  and  productive  environment  among  the  project  team,  the  end  user,  and  the 
contractor  ejdsts. 

The  top-level  activities  performed  for  Contract  Performance  Management  are: 

1 .  The  project  team  performs  its  activities  in  accordance  with  its  documented  contract 
performance  management  plans. 

2.  The  contractor's  software  engineering  process  is  appraised  according  to  the  project's 
defined  software  acquisition  process. 

3.  Results  of  the  contractor's  engineering  activities  are  appraised  according  to  the  project's 
defined  software  acquisition  process. 

4.  Measurements  are  used  to  appraise  the  contractor's  performance  and  trends  analyzed. 

5.  As  understanding  of  the  software  engineering  process,  products,  and  services  improves, 
the  project  team  may  propose  changes  to  the  software  products  or  services,  process 
descriptions,  plans,  and  activities. 

6.  The  end  user  periodically  participates  in  the  evaluation  of  evolving  software  products  and 
services  to  determine  the  satisfaction  of  operational  requirements. 

7.  Contract  performance  management  activities  are  performed  to  foster  a  cooperative 
environment  between  the  project  team  and  the  contractor. 
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Summary  of  KPAs 


. 

Level  3:  Acquisition  Risk  Management 


The  purpose  of  Acquisition  Risk  Management  is  to  identify  risks  as  early  as  possible,  adjust  the 
acquisition  strategy  to  manage  those  risks,  and  develop  and  implement  a  risk  management  process 
as  an  integral  part  of  the  acquisition  organization's  standard  software  acquisition  process. 
Acquisition  risk  management  begins  with  the  process  of  defining  the  system  need  and  terminates 
when  the  software  acquisition  is  completed.  Acquisition  risk  management  becomes  an  integral 
part  of  the  solicitation,  project  performance  management,  and  contract  performance  management 
processes. 

Acquisition  risk  management  is  a  two-part  process.  First,  the  software  acquisition  strategy 
identifies  the  risks  associated  with  the  acquisition  of  the  system  and  the  approach  is  planned  based 
on  those  risks.  Second,  a  process  is  employed  to  manage  the  risks  throughout  the  acquisition. 

Risk  identification  includes  categorization  of  the  risk  based  on  historical  data  and  estimates  to 
determine  the  impact  of  each  risk  on  quality,  performance,  schedule,  and  cost.  The  risks  are 
analyzed  to  determine  their  impact  on  acquisition  strategy  and  software  engineering.  Analysis 
includes  determining  the  driver  of  each  risk  area  and  the  impact  of  the  risk  so  that  risk  handling 
strategies  may  be  proposed  and  tested. 

Acquisition  risk  management  is  planned  through  the  Software  Acquisition  Risk  Management  Plan 
which  details  the  processes  to  take  place  in  acquisition  planning  and  software  acquisition 
management.  The  Software  Acquisition  Risk  Management  Plan  describes  the  overt  management 
actions  and  procedures  to  identify,  analyze,  and  rank  order  risks,  and  the  risk  handling  methods  to 
be  applied. 
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Summary  ofKPAs 


The  goals  of  Acquisition  Risk  Management  are: 

1 .  Software  acquisition  risk  management  is  an  integral  part  of  the  project's  defined  software 
acquisition  process. 

2.  The  project  identifies  and  deals  with  risk  in  a  positive  manner,  such  that  identification  is 
recognized  and  rewarded,  and  results  in  effective  risk  handling. 

The  top-level  activities  performed  for  Acquisition  Risk  Management  are: 

1 .  Software  acquisition  risk  management  activities  are  integrated  into  software  acquisition 
planning. 

2.  The  Software  Acquisition  Risk  Management  Plan  is  developed  in  accordance  with  the 
project's  defined  software  acquisition  process. 

3 .  The  project  team  performs  its  software  acquisition  risk  management  activities  in 
accordance  with  its  documented  plans. 

4.  Risk  management  is  conducted  as  an  integral  part  of  the  solicitation,  project  performance 
management,  and  contract  performance  management  processes. 

5.  Software  acquisition  risk  handling  actions  are  tracked  and  controlled  until  the  risks  are 
mitigated. 
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Summary  of  KPAs 


Level  3:  Training  Program 

The  purpose  of  Training  Program  is  to  develop  the  skills  and  knowledge  of  individuals  so  they  can 
perform  their  software  acquisition  roles  effectively  and  efficiently. 

Training  Program  involves  appraisal  of  training  requirements  at  the  acquisition  organization, 
project,  and  individual  levels.  The  acquisition  organization  surveys  its  current  and  future  skill 
needs  and  determines  how  these  skills  will  be  obtained.  Current  weaknesses  of  the  acquisition 
organization  are  understood  and  plans  are  developed  to  systematically  address  the  weaknesses. 

Some  skills  are  effectively  and  efficiently  imparted  through  informal  vehicles,  whereas  other  skills 
need  more  formal  training  vehicles  to  be  effectively  and  efficiently  imparted.  The  appropriate 
vehicles  are  selected  and  used. 

Members  of  the  acquisition  organization  are  schooled  in  the  standard  software  acquisition 
process,  the  project,  the  domain,  and  in  the  skills  and  knowledge  needed  to  perform  their  jobs 
effectively.  Members  effectively  use,  or  are  prepared  to  use,  the  capabilities  and  features  of  the 
existing  and  planned  work  environment.  The  project  teams  become  more  effective  through  a 
better  understanding  of  their  work  processes. 

This  key  process  area  covers  the  group  that  is  performing  the  organization's  training  function. 

The  processes  identifying  specific  training  topics  (i.e.,  knowledge  or  skills  needed)  are  contained 
in  the  common  feature  "Ability  to  perform"  of  the  individual  key  process  areas. 
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Summary  of  KPAs 


The  goals  of  Training  Program  are: 

1 .  Training  Program  activities  are  plaimed. 

2.  Required  training  is  identified  and  provided. 

3 .  The  Training  Program  fully  supports  the  acquisition  organization's  standard  software 
acquisition  process. 

The  top-level  activities  performed  for  Training  Program: 

1 .  The  organization's  training  program  is  developed  and  maintained. 

2.  Each  software  acquisition  project  identifies  specific  training  needs  and  develops  a  training 
plan  in  accordance  with  training  program  procedures. 

3 .  Software  training  for  the  project  team  is  performed  in  accordance  with  the  organization's 
training  program. 

4.  A  waiver  procedure  for  required  training  is  established  and  used  to  determine  whether 
individuals  already  possess  the  knowledge  and  skills  required  to  perform  their  designated 
roles. 

5 .  Training  records  are  maintained. 

6.  Measurements  are  used  to  determine  the  quality  of  the  training  program. 
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Level  4:  Quantitative  Process  Management 

The  purpose  of  Quantitative  Process  Management  is  to  control  the  process  performance  of  the 
software  acquisition.  Projects  fully  implementing  quantitative  process  management  will  have 
stable  processes  that  are  under  quantitative  control. 

Quantitative  Process  Management  involves  each  project  team  setting  performance  objectives, 
measuring  performance,  analyzing  results,  and  making  adjustments  to  maintain  performance 
within  acceptable  limits.  Process  performance  variations  (i.c.,  variations  attributable  to  specific 
implementations  of  the  process)  are  measured  and  actions  taken  to  bring  the  process  performance 
within  acceptable  limits.  When  the  project  team's  process  performance  is  stabilized  within 
acceptable  limits,  the  defined  software  acquisition  process,  the  associated  measurements,  and  the 
acceptable  performance  limits  are  baselined  to  permit  quantitative  control  of  the  project  team's 
process  performance. 


The  acquisition  organization  collects  process  performance  data  from  the  software  acquisition 
projects  and  uses  these  data  to  assess  the  capability  of  its  standard  software  acquisition  process 
(see  the  Process  Definition  and  Maintenance  key  process  area).  The  capability  of  the  acquisition 
organization's  standard  software  acquisition  process  is  indicative  of  the  performance  that  can  be 
expected  from  the  next  software  acquisition  project  it  undertakes.  These  capability  data  are,  in 
turn,  used  by  the  software  acquisition  project  teams  to  set  their  performance  objectives  and  to 
analyze  the  performance  of  their  defined  processes.  The  capability  data  are  also  used  by  the 
project  teams  in  tailoring  the  acquisition  organization's  standard  software  acquisition  process  to  a 
particular  acquisition. 
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Summary  ofKPAs 


The  goals  for  Quantitative  Process  Management  are: 

1 .  The  performance  of  each  proj  ect's  defined  software  acquisition  process  is  quantitatively 
controlled. 

2.  The  performance  of  the  acquisition  organization's  standard  software  acquisition  process  is 
described  in  quantitative  terms. 

The  top-level  activities  performed  for  Quantitative  Process  Management  are: 

1 .  The  acquisition  organization's  software  acquisition  process  capability  baseline  is 
established  and  maintained  according  to  a  written  procedure. 

2.  Each  project  team  performs  its  activities  in  accordance  with  its  documented  quantitative 
process  management  plans. 

3 .  The  measurement  data  used  to  quantitatively  control  the  project's  defined  software 
acquisition  process  are  collected  in  accordance  with  the  project's  quantitative  process 
management  plans. 

4.  Each  project's  defined  software  acquisition  process  is  analyzed  and  quantitatively 
controlled  according  to  the  project's  quantitative  process  management  plans. 

5 .  Reports  documenting  the  results  of  the  project  team's  quantitative  process  management 
activities  are  prepared  and  distributed. 

6.  Causal  analysis  of  each  project's  defined  software  acquisition  process  is  conducted  on  a 
periodic  basis  to  determine  root  causes  of  variances  from  the  project's  plans. 
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Level  4:  Quantitative  Acquisition  Management 


The  purpose  of  Quantitative  Acquisition  Management  is  to  manage  the  contractual  effort  through 
the  application  of  quantitative  methods. 

Quantitative  Acquisition  Management  involves  utilizing  process  and  product  measurements  as  an 
intrinsic  part  of  management  review  and  oversight  to  quantitatively  manage  the  acquisition  of 
software  products  and  services. 

As  the  acquisition  organization  continues  to  attain  higher  levels  of  maturity  there  is  a  transition  to 
quantitative  methods.  This  transition  is  marked  by  the  involvement  of  all  levels  of  acquisition 
management.  The  result  represents  an  advance  fi-om  contract  performance  management  to 
acquisition  management  using  quantitative  methods.  Another  result  of  this  transition  is  an 
expected  increase  in  the  quality  of  acquired  products  and  services. 

The  quantitative  acquisition  management  process  is  integrated  with  quantitative  process  . 
management.  The  actions  of  quantitative  process  management  at  the  project  level  and  across  the 
acquisition  organization  are  integral  to  acquisition  management. 
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The  goals  for  Quantitative  Acquisition  Management  are; 

1 .  Quantitative  objectives  for  the  acquired  products  and  services  are  defined. 

2.  The  contracted  effort  is  managed  quantitatively. 

The  top-level  activities  performed  for  Quantitative  Acquisition  Management  are: 

1 .  Each  project  team  performs  its  activities  in  accordance  with  its  documented  quantitative 
acquisition  management  plans. 

2.  The  acquisition  organization  utilizes  quantitative  measures  as  a  normal  part  of 
management  review  and  oversight  of  acquired  products  and  services. 

3.  The  quantitative  objectives  for  each  project's  software  products  and  services  are  defined. 

4.  The  quantitative  objectives  for  each  project's  products  and  services  are  incorporated  into 
the  solicitation  package  and  resulting  contract  according  to  the  project's  defined  software 
acquisition  process. 

5.  Each  project's  acquired  software  products  and  services  are  measured,  analyzed,  and 
compared  to  the  project's  established  quantitative  objectives. 

6.  Causal  analysis  of  each  project's  acquired  products  and  services  is  conducted  on  a  periodic 
basis  to  determine  root  causes  of  variances  fi'om  the  project's  plans. 

7.  Changes  are  implemented  to  correct  project  acquired  products  and  services  that  are  out  of 
expected  or  acceptable  bounds. 
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Level  5:  Continuous  Process  Improvement 

The  purpose  of  Continuous  Process  Improvement  is  to  evolve  the  software  acquisition  processes 
used  in  the  acquisition  organization  through  managed  continuous  process  improvement. 
Quantitative  objectives  for  the  acquisition  organization's  standard  software  acquisition  process 
and  the  projects'  defined  software  acquisition  processes  are  the  targets  of  the  improvement 
activity. 

Continuous  Process  Improvement  involves  defining  quantitative  process  improvement  objectives 
with  the  involvement  and  sponsorship  of  acquisition  organization  management.  It  is  a  continuous 
effort  to  proactively  and  systematically  identify,  appraise,  and  implement  improvements  to  the 
acquisition  organization's  standard  so  Ware  acquisition  process  and  the  projects'  defined  software 
acquisition  processes. 

The  commitment  to  continuous  process  improvement  is  acquisition  organization-wide.  Training 
and  incentive  programs  are  established  to  encourage  and  enable  all  acquisition  organization 
personnel  to  participate  in  the  software  acquisition  continuous  process  improvement  activities. 
Improvement  opportunities  are  identified  and  appraised  in  terms  of  how  well  they  move  the 
acquisition  organization  and  its  projects  toward  software  acquisition  continuous  process 
improvement  objectives. 

When  software  acquisition  process  improvements  are  approved  for  normal  practice,  the 
acquisition  organization's  standard  software  acquisition  process  and  the  projects'  defined  software 
acquisition  processes  are  revised.  The  Process  Definition  and  Maintenance  key  process  area 
defines  the  actions  for  changing  the  acquisition  organization's  standard  software  acquisition 
process.  The  Project  Performance  Management  key  process  area  defines  the  actions  for  changing 
the  projects'  defined  software  acquisition  processes. 

The  Acquisition  Innovation  Management  key  process  area  defines  the  actions  for  adopting  and 
transforming  new  techniques  and  technologies  into  the  acquisition  organization. 
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The  goals  for  Continuous  Process  Improvement  are; 

1 .  Participation  in  continuous  process  improvement  activities  is  acquisition  organization- 
wide. 

2.  The  acquisition  organization's  standard  software  acquisition  process  and  the  projects' 
defined  software  acquisition  processes  are  improved  continuously. 

The  top-level  activities  performed  for  Continuous  Process  Improvement  are: 

1 .  The  acquisition  organization  performs  its  activities  in  accordance  with  its  documented 
continuous  process  improvement  plans. 

2.  The  software  acquisition  process  group  coordinates  process  improvement  activities. 

3.  Process  improvement  proposals  are  handled  according  to  a  written  procedure. 

4.  Process  improvements  are  transferred  into  practice  according  to  a  written  procedure. 

5.  Records  of  process  improvement  activities  are  maintained  in  the  acquisition  organization's 
repository  for  software  acquisition  process  information. 
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Level  5:  Acquisition  Innovation  Management 


The  purpose  of  Acquisition  Innovation  Management  is  to  continually  improve  the  acq^uisition 
process  through  the  adoption  and  transfer  of  new  techniques  and  technologies.  Acquisition 
innovation  management  is  a  primary  responsibility  of  the  acquisition  organization;  however,  the 
adoption  activity  is  carried  out  through  individual  acquisition  projects.  While  the  project  can  act 
by  itself,  the  environment  for  adoption  should  be  fostered  and  led  by  the  acquisition  organization. 

Acquisition  Innovation  Management  involves  the  identification,  appraisal,  implementation, 
adoption,  and  transfer  of  new  techniques  and  technologies  that  support  the  software  acquisition 
process.  Techniques  and  technologies  include  methodologies,  tools,  and  practices. 

The  focus  is  on  improving  the  acquisition  process  through  the  adoption  and  implementation  of 
new  techniques  and  technologies.  Adoption  of  new  techniques  and  technologies  is  accomplished 
in  concert  with  continuous  process  improvement  (refer  to  the  Continuous  Process  Improvement 
key  process  area). 

Acquisition  innovation  management  of  new  techniques  and  technologies  encompasses  a  range  of 
possibilities.  These  techniques  and  technologies  are  those  which  are  new  on  the  horizon  or  are 
new  to  the  acquisition  organization  and  have  promise  of  providing  a  better  and  advanced 
acquisition  process.  They  may  range  from  introduction  of  a  new  technique  to  the  project  (such  as 
automated  documentation)  to  adoption  of  a  new  management  strategy  (e.g.,  product  line)  at  the 
acquisition  organization  level.  The  acquisition  organization  and  the  project  act  in  cooperation  to 
implement  new  techniques  and  technologies  that  may  provide  a  specific  benefit  to  the  project,  as 
well  as  an  overall  benefit  to  the  organization. 
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Summary  of  KPAs 


The  goals  of  Acquisition  Innovation  Management  are: 

1 .  The  acquisition  organization  improves  the  software  acquisition  process  through  the 
adoption  and  implementation  of  new  techniques  and  technologies  in  a  proactive, 
normative  manner. 

2.  Participation  in  the  acquisition  innovation  management  process  is  organization-wide. 

The  top-level  activities  performed  for  Acquisition  Innovation  Management  are: 

1 .  The  acquisition  organization  performs  its  activities  in  accordance  with  its  documented 
acquisition  innovation  management  plans. 

2.  The  group  responsible  for  conducting  acquisition  innovation  management  activities 
conducts  routine  and  periodic  appraisals  of  new  techniques  and  technologies  as  candidates 
for  inclusion  in  the  acquisition  organization's  standard  software  acquisition  process. 

3 .  The  project  team  performs  its  activities  in  accordance  with  its  documented  acquisition 
innovation  management  plans. 

4.  The  acquisition  organization  works  with  the  projects  to  foster  an  environment  which 
facilitates  adoption  of  initiatives  beneficial  to  the  acquisition  organization. 

5.  Software  acquisition  management  personnel  are  kept  informed  of  new  technologies. 
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